lacerto
-
Posts
5,768 -
Joined
Posts posted by lacerto
-
-
1 hour ago, roni-p-art said:
In V.2, i have no layers. I am not sure why this is happening. I have about 152 files that i exported to PDF (that at some point need changes in the future ) and i have just discovered the layers are missing.
Do you mean that when transferring v1 .afpub files with "Layer" layers, they do not translate to "Layer" layers when saved to v2 .afpub files?
My understanding is that when you export layers in PDF format from version 2, you will get Acrobat OCG multilevel support both in Adobe Acrobat and when reading these PDF files back into Affinity apps. In version 1 there was only root-level support both when showing these layers in Adobe Acrobat, and when reading back Layer layers in Affinity apps.
So rather than degraded the support for OCG layers has improved. It is another thing that Affinity OCG layers are not global (contrary to Adobe created), and that Affinity created OCG layers are not supported in anywhere else (at least as far as I know) than Adobe Acrobat, and that no other than Affinity apps can read them back. But personally I consider this a valuable feature addition within Affinity apps suite.
-
2 hours ago, Hangman said:
I'm seeing the exact same issue, this definitely looks like a new bug...
I suppose so. This was the first time for me, too, to experience "vanishing" embedded files. I was just perplexed to see the feature suddenly working (and of course at the time I tried to record the behavior). Perhaps the absurd file size (when having mere links) is a related bug, though I have read a few threads trying to explain why linked files can increase the container size (I have an impression that this is more or less a permanent question on the forum).
-
Here the issue is experienced on macOS.
Linking/embedding behavior is very odd within Affinity apps. As can be seen, even if this single file (PDF size of which is on disk about 10MB) is linked, the Publisher document wastes 25MB disk space when the file is saved. On Windows it takes about 11MB, which is a lot, too, for storing information for a single linked file, but why is the macOS version still over double more bloated? As it is, it actually seems that even a linked file is already some way embedded. What is even stranger is that on the video clip embedding does not actually increase the file size at all, while on other occasions (experienced when first testing the behavior before making the final recording) embedding clearly increases the file size. Yet on certain occasions embedding truly happens and the Publisher document file size might nearly double so having a 10MB file embedded might waste about 35MB disk space (on macOS).
There are lots of posts reporting odd and sudden document file size increase, and as the behavior shown on the video does not happen consistently, it is possible that the clip just demonstrates an old bug that does not happen all the time. It might of course be partially a macOS specific issue, too (I am running Ventura 13.4.1 in native mode), but I doubt it because the same behavior can be witnessed on Windows 11, just not taking as much disk space.
-
1 hour ago, Hangman said:
Could you perhaps create a simple Publisher file on Windows (if you have time), place a couple of embedded PDF files in the document, Save it then Zip it up and post it. I'll then take a look to see if the PDFs are still embedded when opened on macOS or whether they show as Linked just in case this is a new v2.1.1 bug...
The behavior is identical on macOS and Windows and you can easily test it by embedding a large PDF file (e.g. one that contains embedded raster images, I tested this with a 10 MB PDF containing lots of low-res images). Then after having embedded the PDF in Resource Manager, save the Publisher document and rename the file that you embedded in the file system, then open the Publisher document. The supposedly embedded PDF file is no longer rendered on canvas and if Resource Manager is opened it is shown as "Linked", not embedded. Any raster images embedded are rendered normally and their status is "Embedded". Notice how Publisher file size nevertheless increases and decreases depending on whether it is embedded or linked (or removed), which indicates that the file would appear to be embedded, but just cannot be rendered.
-
1 hour ago, R C-R said:
it seems to depend on the type of item(s) that are embedded vs. linked
It seems so. PDF files will not be embedded even if their file size is large.
EDIT: But oddly, the file size of the Publisher file does get increased, so it is possible that the PDF files are actually embedded but there is a glitch in the code when it is time to render these files (the embedded resources are not found or something goes wrong in processing, resulting in these files being marked as linked).
-
9 hours ago, Hangman said:
Obviously, that depends on the version of PDF you're exporting to... exporting to PDF 1.7 certainly allows crop marks in placed files to be exported without rasterisation.
Yes, but then the cropping options can mess up the export, at least Maximum and Minimum Content both have been somehow broken for ages. I am not even sure about their purposes but neither e.g. crops the export exactly to the bounding box of the selected objects (the option that is available when cropping an imported/placed PDF within e.g. Photoshop or InDesign). If the design does not have live transparencies, or live transparency is not a problem, PDF 1.7 is a solid choice and crop marks (if any) of objects that have been cropped by using e.g. Media Box or Artbox options, will be included and nothing is rasterized. But if there is a "compatibility rules" based conflict and resulting rasterization, print marks are guaranteed to be included only in the rasterized objects, while they may be omitted for objects that do not get rasterized, whenever using Maximum or Minimum Content crop options.
-
8 hours ago, Hangman said:
Normally, even if the resource is missing, Publisher still shows both the Original and Placed sizes in Resource Manager...
Well, it is obvious that nothing is really embedded in current 2.1.1 versions (at least in Publisher). The status just says "Embedded" as long as the path (which is saved even if the files were actually embedded, which can be seen when making embedded files linked again, since by default the earlier link path will be used). I am not sure how old this bug is, but it can be easily verified just by looking at the file size of the Publisher file supposedly containing embedded files, and if that is not enough, by manually breaking the access to the path where the (actually still) linked files are located. That link naturally breaks when transferring the Publisher file to a different computer or on the Internet (like it did for OP when they uploaded the file on the forum post).
-
11 hours ago, Hangman said:
I guess that depends on the source of the PDF, if it's one you've created yourself and have all the associated 'elements and fonts' for then it doesn't appear to be an issue.
Sorry, a typo, I meant of course "for passthrough" and not "interpretation". If PDFs are safe to be interpreted (e.g. own still editable production), there typically are no problems, as long as there are no profile conflicts (which can easily rise inadvertently because the placed PDFs without an embedded profile will have the working color profile assigned to them rather than the hosting document color profile).
But as for passthrough, whether your placed PDF workflow has any chances to behave expectedly much depends on whether you can choose your production method freely, and what kinds of features you will have in the placed files.
Assuming that the printer requires all in CMYK and no live transparencies, and more specifically PDF/X-1a, as might still be common, and you need to place PDFs and use passthrough, you will have problems, no matter which kinds of PDFs you are going to use.
Below are examples where a PDFv1.4 file has been placed for passthrough and exported to PDF/X-1a:2003, and another example where a PDF/X-1a file has been placed for passthrough and exported to PDF/X-1a:2003. Both scenarios should "in principle" work considering the Affinity "compatibility rules", since the PDF version numbers are the same in source and destination -- so one might assume that just taking care that transparencies (blend modes and opacities) get flattened the file would be easy to produce to meet expectations.
Nothing at all gets passed through: everything is rasterized, including text (not involved in transparencies at all), and all native color values are recalculated and incorrect, and spot colors and overprint attributes lost. All color values (already defined in CMYK) get changed even if the profiles are the same in the placed file, the document and the exported file (though this should not matter when native color values are assumed just to be passed through).
So no news here, I just wanted to test if 2.1.1 has any developments in PDF production, but it does not seem so.
The most flexible export method, using PDF (press-ready) and PDF v1.7, would allow using all kinds of PDFs placed for passthrough, but if transparencies need to be flattened, there is no other option than using PDF/X-1a or PDF/X-3 (and optionally force conversion of placed RGB images), since PDFv1.3 is not supported. And non-PDF/X-based PDFs placed for passthrough will then always be rasterized (even PDFv1.3 files).
But as can be seen, even if PDF v1.7 could be used freely, more "complex" production features, like files using crop marks, can cause problems, and accordingly require allowing interpretation.
-
3 hours ago, Hangman said:
does the same happen from PC to Mac and Mac to PC?
Yes, here it happens when saved on macOS and transferred onto Windows:
As can be seen, I deliberately eliminated the chance that this could have been caused by the OP's missing files. As the OP had placed the files to be passed through, the placement method does not seem to play any role here [I mean in losing the embedded files], either.
-
2 hours ago, Hangman said:
The OP exports using PDF Passthrough rather than Interpret which turns out to be the issue...
Oh yes, I seem to have missed the part they switched back to "Transfer" after first having switched from "Transfer" to "Interpreteren".
Then nothing surprises me. You basically cannot place PDFs for
interpretationpassthrough and export to PDF without experiencing some sort of issue. There are certain specific workflows that can be used without problems, but having e.g. crop marks in placed files seems to work only if the placed files are rasterized (either because of "compatibility rule" violation, or beforehand on the canvas, or intentionally at export time. This has never worked properly in Affinity apps. -
17 minutes ago, Hangman said:
Resource Manager suggests the OP had his or her PDF files Linked rather than Embedded...
Yes, the behavior was identical in my test. I embedded in Windows, closed the document, reopened it and made sure that files showed Embedded in Resource Manager, closed and transferred on macOS, where nothing showed on the canvas, and the Resource Manager showed the status as linked.
Similarly as OP I had placed the PDFs (produced as both PDF 1.7 default and PDF/X-1a from Designer 2.1.1 Windows version) as interpreted and then exported as PDF 1.7 (default) the selected placed PDFs. I used Maximum Content as the crop option, but did not have the placed images scaled or rotated.
So this kind of file:
-
I seem to be able to crop something similar correctly from Publisher 2.1.1 on both Windows and macOS (Win 11 and latest macOS Ventura), but noticed that when initiallly trying to embed the placed PDFs, this failed (similarly as it seems to have failed with OP).
-
23 hours ago, Beruce said:
I've attached two files that illustrate how differently programs deal with this font. The old cs6 illustrator is very well able to display and use the font. It would be nice if the Designer 2 also worked like this.
It does not seem to be as much a question of "old" vs. "new" apps, but the level of support for different standards, some legacy (like non-Unicode Windows or Mac encodings), some new (like variable fonts). All browsers on Windows that I tested (Chrome, Firefox, Edge) can render the SVG test file provided (the one created by AI CS6) without problems, as can apps like LibreOffice Draw, VectorStyler, CorelDRAW (after PANOSE font matching and showing all codepages), Xara Designer, and Krita. But Affinity apps are not alone, so e.g. Inkscape and GIMP cannot, nor can Adobe Photoshop CC 2023. And it seems nothing on macOS can render it correctly (except VectorStyler, after manual fontname mapping; UPDATE: Google Chrome can, without any issues while Safari cannot), so having the support and then capability to change to something more universal (even if just converting to curves, but having correct rendering) and up-to-date is a useful and important feature.
-
If it is a question of having a memory issue at the time of using "Replace image" feature while having the Resource Manager open (either for single or multiple files), using a trick of renaming the original jpgs in the file system, then reopening the Publisher file, and then (when Publisher cannot find the linked files and shows a dialog box warning) choosing "Yes" to relocate the files, but choosing the TIFF files instead of the original JPG files, might be able to avoid the memory issue (as I assume that it technically just replaces filenames rather than tries to allocate memory at the same time, which Resource Manager probably does). Worth a try, anyway.
-
9 minutes ago, GT70 said:
By the way, is there a way to make the space symbol appear like Word does to separate one word from another? I've seen blue dots somewhere, but I don't know how to activate them on Publisher.
Text > Show Special Characters (this shows also many other white spaces and special characters).
13 minutes ago, GT70 said:In any case, I want to clarify that the original file sent to Amazon, the one with the wrong prints, had been generated by Publisher. I didn't use Preview on the original file.
Thanks for the info. Hope the initial issues with transparencies are now history. They might have been a separate issue totally (since I did not manage to reproduce these problems by using the resources that you provided and methods that appeared to have been applied on them). To be sure, you could run PDF/X-1a verifier routine with Adobe Acrobat Pro on the actual production file.
-
5 minutes ago, Hangman said:
Well, the mysterious 1-bit grey image layer is no longer there in @lacerto's last file...
No it is not but since the demo fix was also a Quartz production, I think that the issue is actually caused by extracting demo pages from Preview! So this may be just an illusory issue caused by Preview, and the initial file exported from Publisher is just fine -- just a guess.
-
Btw, I noticed that PDF producer in your demo file was Quartz PDFContext??? Was the file produced (post-processed, saved as, pages extracted) in Preview and not directly in Affinity Publisher? This could well cause all kinds of issues, especially if you try to produce a standard PDF/X-1 file...
EDIT: If this was done only for extraction of pages but you create the actual print file using Publisher, and PDF/X-1a:2003, as shown in your screenshot, I do not think that there will be issues. Good luck!
-
Yes, a level adjustment. I'll try to reproduce this on macOS Publisher v1 version -- I tried already on Windows v2 but there could not recreate the issue...
EDIT: Could not reproduce this (by converting the PNG file you provided into a picture frame, cropping it and applying Level adjustment; it exported without problems to PDF/X-1a without transparencies). Perhaps there is something else on the page that causes it, another adjustment placed somewhere on upper layer, e.g. that hand image?
-
What is the "regolazione livelli" that you have applied on the image? It is probably this that causes the "SoftMask" and does not get flattened at export.
-
The fixed file still showed the same issue. I ran a Convert to PDF/X-1a fix (using Coated Fogra 39, as did you; note that it might be better to use US Web Coated v2 instead, but I do not think that running the fix changes the TAC, though).
demo2 correct with Adobe_fixed.pdf
Running PDF fix is of course one way to resolve this, but I would try to find out the actual cause for the error. I could not reproduce it by converting the PNG image you provided to a Picture frame but then again I imported the image from file system rather than via Clipboard from a video app. Anyway, just converting to picture frame and cropping did not leave any transparency in the image when exporting to PDF/X-1a from Affinity Publisher.
-
27 minutes ago, GT70 said:
I will point out that these are screenshots taken from the video of the film. Dealing with film images for the most part I had to make screenshots from video.
Sorry, I misinterpreted the Italian language menus and can now see that you actually converted the images to picture frames (rather than image layers). The problem is not in the images themselves, and I could not reproduce the problem by just converting the image into a picture frame, either. Do you have any F/X or adjustment layer applied on the page where the problem occurs (p.52)? Basically if there has not happened any error in exporting to PDF/X-1a, this should be a fool-proof method to flatten transparencies so it would be really interesting to find out what causes this.
-
8 minutes ago, GT70 said:
Basically for almost all the photos I needed to rearrange, I turned them into picture frames as in the picture.
I was wondering why since if you place or paste raster files (from file system or stock photo site), or screenshots, they already are image layers.
-
Ok, thanks. The specific transparency that existed on that image was "SoftMask". It may exist in the placed image already, and Affinity apps might fail to flatten that kind of transparency during export. I have not seen this happen before so it would be interesting to examine this closer. Can you post that image on the forum (zipped, if possible)?
-
Perhaps something went wrong with the export because when I run compliance test against the demo file, I get the following results:
...so this file would fail in any automated prepress check possibly done in context of file delivery.
PDF LAYERS V2 - DON'T WORK THE SAME AS VERSION 1
in Affinity on Desktop Questions (macOS and Windows)
Posted
I tried to upload both the .afpub and PDF files to show the difference but the forum keeps on rejecting my .afpub uploads.
I am attaching them here as a zip file and hope they finally get through.
layersv1vs2.zip
What these files show is that when v1 .afpub is opened and upgraded to v2, the document structure can be exported to PDF layers and read back at levels beyond 1 (I have tested up to level 3 which is already good, but have not checked if there is a level limit).
This is interesting because as far as I know PDF specs allow multilevel OCGs but in practice I have not seen other than Affinity apps utilizing the capability. It is probably related to the fact that Adobe apps use OCG layers at global level as e.g. language/translation levels throughout the document, while Affinity apps use them at per page level. At page level multilevel hierarchical grouping is useful while at document level less so. Adobe apps also enhance PDF and EPS exports by including native AI layers in them so there is obviously no need to support reading back OCG layers within Adobe apps. Anyway, OCG might become a useful method of providing multilevel organized document structure e.g. for print production and accordingly avoid the need to provide Ai compatible EPS and PDF files for postprocessing.