Mike W077
-
Posts
93 -
Joined
-
Last visited
Posts posted by Mike W077
-
-
Yes, this is an issue. It's a production issue, too, not just a feature issue, so it seems like it should be high on the priority list to address.
-
Cannot seem to select the contents of the picture frame by using Cmd+Click. Am I missing something?
-
5 minutes ago, akula7 said:
The question remains whether the developers are aware of this problem. Affinity is really a great suite, but without this problem being erased, Publischer really cannot be used professionally. I haven't heard any comments from the developers, maybe they don't know that this is a real problem?
Man, I don't know. It does not seem possible that they are not aware of it. However, stranger things have happened. How do we let the developers know other than posting here?
Is it some sort of strange licensing issue with Adobe? Does Quark have the same problem? Hmm. Stumped.
BTW, I just tried some additional experiments yesterday. Same result. Anything created in APub that is exported to PDF retains its original CMYK values. However, any PDF imported and placed into an APub page, say an element from Designer, then re-exported from APub using PDF has its CMYK color values shifted dramatically. This is especially true with 100% black in a placed PDF, upon export to PDF from APub, being shifted to an almost equal mix of CMYK. Sorry, I can't use that when I go to press. Still back with InDesign. Bummer.
-
On 5/12/2023 at 7:31 PM, thomaso said:
The 'easiest' would be to avoid colour conversion between APub and placed document and export, by setting both files, .afpub and afdesign, to the same colour space & profile and export with this profile "As document" (in Export > More > … ).
Thank you for the replies. I will try the suggestions (away from the office at the moment). But, bottom line, no one so far knows a straightforward fix. Hmmm. InDesign just leaves the values the same when exporting placed CMYK PDF content to InDesign PDF. APub changes them. If one of these works, at least we could work them into our work flow.
-
OK, here's the deal. Whenever I "place" anything created outside Affinity Publisher into Affinity Publisher, and then export the publication to PDF for CMYK printing, APub changes the CMYK values in the placed file!
I have tried placing PDF files and Affinity Designer files, always the same result. I have tried every setting I can think of under preferences and PDF export that I can find. I don't want this! Why does it do this? I want to stay with APub, but this issue has me and our publishing company back with InDesign.
I export to PDF from Designer, color values remain correct. I import the same file to APub, then export the page to PDF, the color values have changed! This is especially vexing with 100% black, which ALWAYS gets changed to a combination of CMYK values. My printer can't work with this.
However, if I fill a square with 100% black in APub, then export to PDF, the color value remains 100% black. Argh! But, if I import a PDF or a native Designer file, then export the page to PDF from APub, I get a mix of CMYK values instead of 100% black. Argh again!
This CANNOT be right. There HAS to be a simple switch fix for this. Surely SOMEBODY out there has solved this. Please help!
Thank you in advance.
-
Publisher is the hub of Affinity's entire effort. They HAVE to make this program work. They need to FIX the PDF export issue also, ASAP. If you set the CMYK color values in Designer, then export to PDF, those color values should remain the same. Then, if you place the PDF in a Publisher document, as most designers do, and then output that document to PDF to send to the printer (thus having PDFs embedded in the Publisher PDF container), the CMYK color values in the embedded PDF (originally created in Designer, exported to PDF, placed in Publisher, and then embedded in the resulting PDF exported from Publisher), SHOULD REMAIN THE SAME! But, currently, they DON'T! No professional can work with that.
-
11 hours ago, JEP said:
This STILL is not fixed on the newest Beta version (2.1.0.1736)!
Are we ever going to get a fix for this?
Still not fixed. I've given up. Using Indesign. They are clearly not aiming this for professional use. Wake me when they fix this and the PDF export nightmare.
-
1 hour ago, lacerto said:
There are other production quirks, too. All this means that in more complex productions some kind of prepress software is required not only to do proper preflight, but sometimes also to make corrections to production PDFs themselves.
You seem far more knowledgable on this than I am. What I know is that this last issue we went back to InDesign and things seemed to go smoother at the press, even though it was a bit of a re-learning curve for us. I really like Apub and Affinity products to use, and like Serif as a company, but if the suite is going to be used for serious production work, at least for us, I feel that this needs to be fixed. Again, thank you for your thoughtful and helpful posts.
- Buglover, debraspicher, Ldina and 3 others
-
6
-
On 3/12/2023 at 1:13 AM, lacerto said:
The whole package is quite complex, but here are few rules of thumb whenever placing PDF content and exporting to PDF, and PDF/X is involved either in export or placement:
1) If there is placed content using PDF/X-1a or PDF/X-3 (which are version 1.4 when produced from within Affinity apps), you need to export using PDF/X-3 or PDF/X-4, or any non-PDF/X-based method, to not cause rasterization / translated color values (e.g. rich black).
2) If there is placed content using PDF/X-4 (which is version 1.6), you need to export using PDF/X-4, or any non-PDF/X-based method using PDF version 1.6 or later, to not cause rasterization / translated color values (e.g. rich black).
3) If there is non-PDF/X-based placed content, you need to export using non-PDF/X-based method using the same or later PDF version than a placed PDF content, to not cause rasterization / translated color values (e.g. rich black). The most compatible choice would then be PDF 1.7. Whatever the non-PDF/X-based choice used, live transparencies (opacity values and blend modes) would not be flattened (because Affinity apps do not support PDF version 1.3, which would cause flattening). In Affinity apps transparency flattening is only used in PDF/X-1a and PDF/X-3.
4) Placing PDF as interpreted causes failure to read the overprint status of native objects. Also, if the files use embedded CMYK profiles and there is a conflict with the export target, or if the files do not use embedded CMYK profile and the document working profile (as defined in Preferences) that these files will be assigned with, and there is a conflict with the export target, CMYK color values of the placed PDF content will be translated at export time. This basically corresponds a situation where non-document CMYK profile is defined at export time. Letting Affinity apps interpret the placed content may also result in failure to map fonts (even when they are installed on the system), especially if the PDFs have been created with non-Affinity software (e.g. Adobe apps or CorelDRAW), even on the same computer.
Here are demo files:
a) Miscellaneous placed PDF content exported using PDF/X-1a (all placed content will be rasterized):
pdfxcompatibility_pdfx1.pdf 5.26 MB · 0 downloads
b) Miscellaneous placed PDF content exported using PDF/X-4 (non-PDF-based content will be rasterized):
pdfxcompatibility_pdfx4.pdf 2.94 MB · 0 downloads
c) Miscellaneous placed PDFC context exported using non-PDF/X-based PDF1.7 (note that Adobe Acrobat Pro shows the color values of the non-PDF/X-based PDF at the lower left corner incorrectly; the true color values are shown using the Object Inspector of the Output Preview dialog box):
pdfxcompatibility_pdf17.pdf 762.37 kB · 1 download
d) Example of an export file (PDF/X-4) using interpreted placed PDFs (note the lost overprints):
pdfxcompatibility_pdfx4_interpreted.pdf 1.85 MB · 1 download
A couple of further notes:
- Affinity apps always convert RGB values of native objects (shapes and text) to CMYK, also when using PDF/X-3 or PDF/X-4 which allow RGB definitions (this is unlike e.g. InDesign). Additionally, PDF/X-3 also converts image color spaces to CMYK, disregarding the value of "Convert image color spaces" setting...
- When using PDF/X-1 or PDF/X-3, all transparencies are flattened by using rasterization instead of Boolean operations (which are tried to be used when exporting from Adobe apps or QuarkXPress).
A long story short: Export using PDF/X-4 (while having the content placed to be passed through), or using non-PDF/X-based version 1.7, and if using the latter, remember to uncheck the "Embed ICC profiles". The latter will keep placed non-PDF/X-based content unchanged, the former will not. In both cases, your export files will contain live transparencies, in case not flattened in the placed document or on the canvas. If you need to export transparency flattened PDF/X-1a content and you have them in placed PDF/X-4 content, you are out of luck. That means: the content will be rasterized unless you can flatten it in the source files and reproduce.
Note: These tests and files have been created using the 2.0.4 Windows version of Affinity apps, but versions 1.10.6 and the latest v2 beta behave similarly, on both Windows and macOS.
This is an amazing and exhaustive explanation. Thank you for your work. It also reveals a system that is WAAAAY too complicated for a production work flow. It shouldn't be this complicated. There should be a simple way to allow specified CMYK colors to flow through the export processes unchanged. We receive way too many PDF placeable files from customers and agencies, as well as elements — logos, other art — that we design up ourselves — to make anything this complicated work. APub should just let everything flow through to the final PDF, including the random RGB, and then let the RIP at the printer handle the interpretation. That's its job. That would make sure that specified CYMK values remain unchanged and let the RIP interpret the rest for best output. As it is, with APub apparently wants to interpret ALL color values if there are ANY rasterized or RGB elements in the publication — if I understand this correctly (and I might not. It is complicated.). Thanks again for your help and your work. I will review more extensively.
-
On 3/8/2023 at 11:28 PM, laurent32 said:
Another dumb question (maybe ?)…
I remember having read "path through" possibilities when importing PDF.
And if I understood it correctly, the imported PDF would be treated differently ?
Have you tried that ?
Yes. Works for fonts. No difference on color changes.
-
3 minutes ago, Old Bruce said:
Here is my dumb question: Are you using a Print preset or a Press Ready preset? The former is RGB while the latter is CMYK.
No worries. The PDF presets for professional print work, i.e., X4 or X1-a, are for CMYK, and that is what we use.
-
OK, you Publisher ninjas out there. Here is a tough, weird one:
THE BACKGROUND: We publish a large circulation (15k+) monthly magazine style newspaper on 32# newsprint on a cold-set web press. We set up the ads and special elements in Affinity Designer and export them to PDF/X-4 or X1-a. The color profiles for the document and the export are set up for newsprint. We also set up the Cover in Designer and export to PDF, have used both X4 and X1-a. For all of these, we set up the Ink Percentages just as we need them for the press.
THE PROBLEM: When we export from Designer and check the Ink Percentages in Adobe Acrobat (Print Production/Output Preview), the ink density percentages are just as we set them. However, when we Place the PDFs exported from Designer into the publication in Publisher and then export the entire publication to PDF, either X-4 or X-1a, the colors SHIFT AND CHANGE. One major issue is black (the K in CMYK). There are times when the black needs to be 100% and the rest of the colors 0, and not a "rich black" (a mix of black with other colors to give it more richness). However, 100% black in PDF elements placed into Publisher ALWAYS seem to shift to a form of rich black, and other color densities can shift also. This even happens when we take the native Affinity Designer files and place them in Publisher and then export to PDF. When we export to PDF and check the colors with Acrobat Output Preview, the colors have shifted. We get rich black when we wanted 100% black only. When we sent these files to our printer, they cause no end of headaches with color separation and registration issues.
Yes, we tried setting the Assign/Convert under the Color setting in document setup to "Assign," but it automatically switches back! Argh!
Please don't just tell me to try various different color profiles and export settings. Have tried that approach and no color profile settings or export setting changes seem to make a difference. It seems to be a problem with the way the PDF export engine is implemented in Publisher. Am I wrong about this? Or maybe there something I'm missing. I have searched the forums and can't seem to find anything specific, although I seem to recall someone else having this type of issue too, but can't find it again.
Here's how bad it is: Due to this and the inexplicable unchangeable default text box margin spinner settings in APub 2.0, we have gone back to InDesign. Color settings stay solid as a rock even after exporting to PDF with PDFs placed in the publication. However, I am still holding out hope for APub.
OK, ninjas, anybody else run into this problem and have a fix for it. Fingers crossed.
-
21 hours ago, R C-R said:
After all, what other choice do you have if you are working in V2 of APub on a Mac? You obviously can't just wait until the fix is implemented, right?
After a while, all the little "gotchas" get to be too much. The 0,0,0,100 random conversion to rich black in PDFs (making problems with registration. This may be fixed in 2.X, but don't know for sure), the lack of span columns for paragraphs, and now this. Just little things that are really big things in a production work flow. There is another option, going back to InDesign, at least until these issues are resolved. Not what I want, but it is an option.
-
1 hour ago, JEP said:
Yes, entering a small value works, but is veery time consuming.
I'm attaching screen recording that shows this.
The inset settings & defaults worked perfectly in V1--can't they be restored for V2?
Do you have an idea of if or when we could expect a fix for this?
Awesome! Good job. Thank you. Come on Serif! Get this fixed. Those of us using Publisher for production need this fixed ASAP.
-
15 minutes ago, R C-R said:
I agree that it takes more steps & is far from ideal, but I just wanted to make sure manually entering small values was working for you & not an indication of some additional bug in the Mac version I was not seeing.
Thank you for checking back on this. Do you have an idea if or when we could expect a fix for this? Thanks.
-
11 hours ago, JEP said:
I'm not sure who actually would use insets in 1.0" increments (useless except for enormous layouts).
I'm hopeful that the next release will fix this problem. Is there anyway to know when the next release might launch?
Well said. Who needs 1.0" adjustments? Then there is the 0,0,0,100 color issue exporting to PDF, which often converts to a rich black. Argh! This has caused me no end of grief with my printer. Affinity wants us to use these programs for production work, right? Then, they have got to give attention to these kings of details.
-
On 2/1/2023 at 1:42 PM, walt.farrell said:
On Windows, for both V1 and V2, in those fields when the document is in inches:
- Arrow up/down is .01 inch
- Ctrl+Arrow up/down is .001 inch
I wonder why its an issue on the Mac?
-
On 2/3/2023 at 2:07 PM, R C-R said:
Can't you just enter the numeric value in the field manually?
Sure, but it adds steps, including changing from mouse to keyboard, when simple mouse clicks used to work.
-
Has this issue been solved in Publisher 2.X? It has caused me huge headaches with my printer.
-
On 2/1/2023 at 1:30 PM, PaulEC said:
Have you tried using Command instead of Option?
Yes, tried all the options I could think of. No joy. Either 1" or .1", not .01" at a time.
-
On 2/2/2023 at 1:49 AM, loukash said:
Some of these fields directly depend on the respective Decimal Places settings in Preferences > User Interface. Given that I have all units set to 6 places, some fields will increment by 0.000001…
It's a programming flaw or a bug.
I checked and rechecked that too. I think that is the display number places, not the adjustment increments. 😞
-
On 2/1/2023 at 5:31 PM, MikeTO said:
I tested all the combinations (up/down arrow keys, mouse scroll wheel, and spinner controls) on macOS for the inset and gutter width fields. I confirmed the one regression Mike W077 reported and two issues that have been there since v1. The good news is that the effects of the arrow keys, scroll wheel, and spinner were all consistent.
Text Frame panel> Insets:
- No modifier = change by 1 mm, 1p, 1pt, or 0.01 in (v1) / 1 in (v2) - this must have been changed by accident
Text Frame panel> Gutter Width:
- No modifier = change by 1 mm, 1p, 1 pt, or 0.01 in.
Context Bar > Gutter Width:
- No modifier = change by 1 mm, 1p, 1pt, or 1 in which is inconsistent with the panel. But no change from v1.
In all cases, Option changed by 1/10th and Shift changed by 10x. For picas, the modifiers should change by 1/12th or 12x.
Thank you.
-
On 2/1/2023 at 1:42 PM, walt.farrell said:
On Windows, for both V1 and V2, in those fields when the document is in inches:
- Arrow up/down is .01 inch
- Ctrl+Arrow up/down is .001 inch
I'm envious. Definitely not for the Mac versions. Everything is set for inches, but the "spinner" controls (Just learned that term here) only work by whole inches or, with Option-click up spinner arrow, in tenths — .1 instead of .01. Tried every key combination I could think of. No joy. Bummer, because we need that fine control.
-
On 2/2/2023 at 8:04 AM, Pauls said:
I've added a note about the number of decimal places affecting the default increments
Thank you. We really can't use the upgrade until this is fixed, and since Designer 2.X files can't be placed in Publisher 1.X, both 2.X programs are not useable for us at this time. Bummer, I was looking forward to implementing versions 2.X into our workflow.
How do you adjust kerning in Designer?
in Pre-V2 Archive of Affinity on Desktop Questions (macOS and Windows)
Posted
CorelDraw was (is?) great in this feature. We published a newspaper in the late 90s and started a new one in 2019. Used Corel products before. Moved to Affinity and Adobe and it is still shocking to me some of the features we took for granted then are still not implemented in these other programs today. One of the killer features of Corel Ventura page layout program (RIP) was the paragraph tool which allowed for choosing non-contiguous paragraphs, like article subheads, and clicking on one style to change them all at once. In AP and Indesign, you have to format each paragraph on the same page/spread individually. What a pain. Also, since I'm on a roll, the late-90s ACT CRM was perfect for small business. Didn't try to do too much, but still networked and integrated with Outlook and Word for email and letters. In 1998. Today, EVERY CRM is too heavy and tries to do too much. The learning curves are worse than coding. SMH.