lacerto
-
Posts
5,783 -
Joined
Posts posted by lacerto
-
-
A few further notions:
- Compatibility: PDF/X-4 => This is basically in conflict with a recommendation of converting to target color space (whether preserving or not existing color values) since PDF/X-4 by default allows mixed color modes and e.g. in InDesign the default is that colors are not converted but kept, and all involved profiles embedded. So at least check what PDF standard (X-mode) your new printshop recommends, if any...
- Color Space: As Document => Assuming that your document color space is CMYK
- Convert image color spaces: Unchecked => This option is the closest to what InDesign's "Color Conversion" option does: if conversion is used, at all, all RGB images will be converted to target CMYK color space, so in this context this option should be checked.
-
One crucial question related to use of export time color profile change is the purpose the conversion is wished to be used, and whether there are placed CMYK images involved. In InDesign "Convert to destination (preserve numbers)" allows export-time conversion of placed CMYK images with embedded or individually (in context of layout) assigned profiles, making it possible e.g. to repurpose a job inherently designed for coated paper to be used in newsprint (with recalculated TAC values). "Preserving numbers" would in such cases allow recalculation of placed CMYK content with conflicting color profiles, while keeping the native CMYK definitions (in text and shapes).
Reassigning the document with an alternative color profile within Affinity Publisher (using File > Document Setup > Color) does allow "preserving numbers", but there is then also no way to export and recalculate color values of placed CMYK image content (since it will be done only if there is a conflict between the document and target profile). This kind of need, however, is today pretty marginal since the placed image content should ideally be in RGB color mode, in which case colors would be converted correctly to repurposed target whenever exporting to CMYK (while keeping the current document color profile).
-
Your printshop might be willing to run two simple routines on a kind of a grayscale PDF that you can produce with settings I described above without making any changes in the document, and make your production file fully PDF/X-1a-compatible, keeping text as text and as K-100 and images true grayscale.
Rasterised text example_gray_to_konly_pdfx1a.pdf
UPDATE: The file above was created with Adobe Acrobat Pro 2020 conversion routines, but I now tested PDF Tools by Tracker Software (only for Windows, perpetual license about USD82), and it can do it, as well. RGB (e.g. PNGs with transparency) images can be effectively auto-masked with 1-bit raster images and optionally converted to grayscale or target (four-color) CMYK. Verifies 100% PDF/X1a-compliant with Acrobat Pro preflight tools.
-
Yes, this happens. You can still place PDFs containing 16-bit images for passthrough (even if the hosting document is 8-bit, or even in different document color mode, which is a bit surprising), and retain their color depth when exporting.
-
2 hours ago, LizC said:
I have to use this type as the printer specifies it
Just beware of the color conversion issue, so if your printer expects a black ink only job, using PDF/X-4 will convert all black (RGB 0,0,0 or Gray 0) text in your job to CMYK. PNG images will stay RGB grays, and if retained as RGB, will typically be also converted to CMYK grays on RIP.
If PDF/X-1 or PDF/X-3 is really required, it might be easiest to just process images in batch and flatten them and place in the back (without pinning them inline), or crop / create wrap arounds. Depending on the amount of images, it may be a bit painful so there might be point in consulting the printer. They often recommend PDF/X-1a specifically because it makes sure that everything is in single color space (CMYK), and that gray values get interpreted as K values (not converted to four color, as they do in Affinity apps).
-
-
You can also use the "Transparent Background" setting (under File > Document Setup > Color) to have transparent document background to have the whole artboard exported via File menu without a white background.
The Export Persona basically handles artboards as layers and the whole document as background and therefore exports artboards transparent disregarding the document based transparency setting.
- Oufti and Cobalt7 Imaging
-
1
-
1
-
You are probably on macOS because on Windows all color profiles are basically in the same system folder (while within Affinity apps you can -- and at least earlier, specifically when using Affinity app store versions, have to -- place profiles in user and app specific locations to have them available.
For users on Windows, the easiest way to make color profiles available for any color managed app is simply to select an .ICC profile file in Windows Explorer, right click, and choose "Install Profile" from the context menu.
-
As you have a gray-based document color mode, I would recommend exporting using these kinds of export settings:
Compatibility version [PDF version numbers supported within Affinity apps, i.e., from 1.4 to 1.7 -- and now also 2.0] could basically be anything (all they support transparent raster images, so PDF/X-4 or "higher" is no requirement; it is just that PDF/X-1 and PDF/X-3 force flattened transparency and Affinity apps only can flatten by rasterizing, causing this unwanted side effect).*
Exporting explicitly to gray and using the document color profile, as well as forcing conversion of image color spaces, should allow you to keep the exported document in mono color space. Exporting to CMYK (e.g. PDF/X based formats) would just convert your RGB based 0, 0, 0 in text (basically same as Gray 0 in Affinity apps), and RGB-based gray images to four-color black, which you most probably do not want.
Rasterised text example_gray.pdf
* The terminology I am accustomed to use is Adobe-based where PDF version number determines the "compatibility level", and PDF/X method the "standard".
-
I do not remember to have added any standard sizes in v2 apps, but A2, A1 and A0 seem to exist as predefined document sizes both under Print and Press groups on Windows platform. For some reason A2 is listed last within both groups (which might indicate that it has been added manually, but as mentioned, I do not recall having done this).
EDIT: On Windows, having first defined one document size (e.g. A3) and then choosing File > Document Setup, also seems to give the full set of predefined document sizes (and correctly arranged, too):
-
@thomaso -- your solution combined with optical alignment applied on non-breaking space actually works very well, and I think is quite versatile (it allows random breaking points while keeping readability, searchability and editability, and does not require additional PDF round which is a definite weak point if anything more complex than text is involved).
[UPDATE: Conversely, using the PDF trick would allow keeping grammatically correct word breaks but just without hyphens.]
-
-
If you want to retain text readable to certain extent (e.g. to be searchable, readable aloud, etc.), you might consider a trick where hyphenated text exported to PDF is opened back in Publisher using the option that favors fidelity over editability:
and then use Find/Replace to remove hyphens in one go. A PDF opened this way places paragraph breaks after each row so you could not reflow text anymore, so this would be the last stage in this kind of text production. By using manual hyphenation (soft hyphens, Shift+Ctrl/Cmd+dash), or possibly intentionally wrong language dictionaries you could cause seemingly random word splitting.
a) When editing the text (full editability/readability/reflowability retained, words splitted seemingly randomly and partially in wrong places with soft hyphens):
b) Exported PDF opened while stressing fidelity (and hyphens removed using Find/Replace):
Note how the right and fully left justified paragraphs (in the middle and bottom) retain their alignment after hyphens have been removed because paragraphs use optical alignment to place hyphens off the column margin.
textflow_split_no_hyphens_final.pdf
[As can be seen in the final PDF, continuous text flow is/can be retained in text, while keeping text as searchable and readable English.]
-
I consider it as a bug judging on how these objects are rendered on screen and get rasterized to e.g. JPG, and how they are exported to e.g. PDF or PSD.
a) Rendered on canvas (or rasterized as e.g. JPG):
b) Rendered as PSD (IMO logically correctly, clipped and no reverse effect, defining shape still present):
c) Exported to PDF (again, rendered correctly):
-
IMO this appears to be more a kind of accidentally available feature, considering that there is no such prerequisite for using the same keys for zooming when viewing raster images (you can have text cursor left in a text box that has keyboard focus). The vector preview also gets rasterized (becoming jagged) at some zoom stage. Considering that in v1 apps preview was available only for raster images, it seems that preview of vector formats is simply just left in a kind of an alpha stage. [UPDATE: I tried now and zoom is not similarly available on Windows. Additionally, it seems the limitation applies to all "document" formats, including PSD, which in version 1 of Photo did not have preview, either.]
-
You could use something like autonumbering list with a flow setting applied in paragraph style that starts in a new frame after each paragraph break, like attached below:
This would allow you to restart numbering on any page you like. Doing it with sections and page number marker on a master page would be much easier but obviously you have some specific reason to not use sections for this (e.g. in context of multiple master pages).
I am not sure but I think that InDesign automatically applies section page numbering when exporting to PDFs but it seems that Publisher won't do this [EDIT: both assumptions confirmed, so ID created PDFs honor section page number labels while Publisher created PDFs do not], so if you want the PDF to reflect your custom page numbering, you would need to use some PDF editor (like Adobe Acrobat Pro or DC, or PDF-XChange) to apply sections and custom page labels [so that users can see and e.g. go to specified page using the document's custom page numbering], like in the PDF below:
-
Ok, for me (on Sonoma and 2.3) the only zoom that would work like this within Affinity apps (and with PDF export) is this accessibility feature (which below is just temporarily enabled; the feature IS enabled by default on Mac, and I spent some time to find out how to disable it):
-
3 minutes ago, Hangman said:
Personally I don’t understand the logic for the decision but it is still possible to zoom PDF previews on macOS (unsure about Windows) only not with the keyboard shortcuts…
Do you mean system zoom (basically an accessibility feature)? If so, then on Windows invoking Magnifier does the same thing. I have disabled the feature on both operating systems so I cannot have any kind of zoom in preview for PDF exports (or then just cannot access the feature 🙂.
-
There also seems to be (at least on Windows) either a bug, or oddly behaving feature, related to preview of PDF exports, where the above mentioned keys (e.g. for zooming) do not work. The preview image is basically always scaled to fit the preview window width (though there seems to be max width), and cannot be changed while the window is opened (so the preview image does not rescale if the window is made wider or narrower). The last used window width however is remembered so the next time the preview image will be scale up to the same width.
-
I did a quick reality check and opened AI CS6 sample art "Modern Day Venus.ai", "Looking for adventure.ai" and "Nature's Journey.ai", 38MB, 2.8MB and 11MB files showcasing some of the then new CS6 features, in VectorStyler, CorelDRAW and Pixelmator.
VectorStyler did now mostly pretty good job (something that it previously did only with very old AI and Illustrator EPS files), and also could export decent printable PDFs. CorelDRAW did pretty much similarly, both having their own strong and weak spots. Neither could render the tested designs fully, but opened the files quickly, retained very much of the editability, and could export reasonably well-working PDF right out of the box. Pixelmator did mostly fine in rendering, but was extremely sluggish both when opening and exporting (though it must be noted that I tried this on an 8GB MacBook Air using M1), and exported really poorly (bulky files causing all kinds of rendering errors and warnings in Adobe Acrobat Pro and even crashes in Packzview) -- but might still be a useful tool on macOS for at least simple jobs that need to get converted from AI (especially considering the price -- now 50% off -- and versatility). But yes, basically one still needs the real McCoy to open these kinds of files properly.
-
Note that if you have the font available already within Adobe (CC) apps, then you have "added" it, and you can use the CC Desktop app to install the font to be used with non-Adobe and non-CC based apps.
If you need to add new fonts, go to Adobe Fonts, and "add" the fonts required:
After having "added" a font, and you need to have it available universally, use the CC Desktop app, as advised.
I think Adobe has changed this a bit recently so it has become more cumbersome to directly install Adobe CC-based fonts for general use. I think that "added" fonts used to be installed previously, even if they might have required re-activation after a while if not used frequently. Adobe also recently stopped selling FontFolio 11.1 so now they basically only have CC-based font service.
-
Please note the difference between "added" and "installed" fonts. You need to use the Adobe CC Desktop app to manage fonts so that they become installed and available to non-Adobe apps:
-
In context of this singular case (though without having seen the source document structure), it seems as if SVG export/import had weakened, but if objects are actually given names in Affinity apps (shown non-grayed in the Layers palette), they do get exported with ids, including additional serif-ids, even if typically buried in (at least seemingly) superfluous containers.
a) Original Designer source with auto-names, explicit text layer names, explicit Layer containers, and named Group containers:
b) Exported to SVG and opened back:
c) In SVG Code (viewed in Notepad ++)
In light of this example, it seems that the most effective way to organize a complex design is to simply just give Affinity objects (regular layers) names, instead of grouping and organizing them in Layer layers. At least if exchanging data via SVG.
-
I understand these in terms of rasterization.
F/X Gradient Overlay will always be rasterized when exported to PDF, but (with live transparency retained) can have edge colors with transparency smoothly (probably including some feathering) blended into whatever background color, and Fill Opacity box of the F/X panel that allows controlling to what extent object's own background color will be blended in (if at all). It can also be applied on raster objects, retaining its editability.
Gradients applied on vector shapes by using the Gradient Tool, however, are rendered as Radial Shadings and are retained as vector objects when exported to PDF. Basically they are useful only when applied to vector shapes; also, when rasterized on canvas (or as a result of transparency flattening forced at export time), they have antialiasing applied at document DPI resulting in narrower (but often also jaggier, depending on the resolution) transition to background colors compared to F/X gradients, being a bit blurred because of the feathering effect.
The following clip and the PDF try to demonstrate the difference:
Picture files names table of content -- how to?
in Affinity on Desktop Questions (macOS and Windows)
Posted
If the amount of images is remarkable and the project is well planned, one option would be to use Publisher Data Merge to fetch the images and image file names from an Excel sheet. The field that picks the filename could then have a paragraph style with invisible fill color and the text field receiving the filename would be grouped with the picture frame so that it can be easily moved together with the image.
Then, when you do the layout, you would copy the images from the generated merged image publication and position and size the images in the actual layout, and then create a separate TOC for the images. The following screenshot shows just the merged file where each image is on a separate page:
If you have lots of images, you could use the Merge Data Layout tool and merge e.g. 100 images per page and then copy paste the generated image packages (above the filename and image itself wrapped in a picture frame control and grouped in MyImage groups) into the publication layout.
On Windows you can use Windows Explorer to copy filenames onto Clipboard (Ctrl + Shift + C, or Copy as path from the context menu) and then place in Excel sheet:
You could of course use the same method to include whatever image data, as Windows is capable of showing lots of file related (e.g. EXIF) data as extra columns in context of filenames listed in Details view of Windows Explorer. [You would need e.g. the free PowerToys Text Extractor to grab text on screen in table format); for professional projects, I would recommend e.g. xplorer2]. When using an Excel sheet, you could also easily include image captions to be used in context of images.
The following shows how captions could be added as Comments in Windows Explorer and then copy pasted onto an Excel sheet:
You might be able to do something similar also on macOS.