k_au
-
Posts
102 -
Joined
-
Last visited
Posts posted by k_au
-
-
-
If some other users can confirm that this now works on their machines, too, I'd like to add [solved] to the title.
-
I've done a few tests with 2.40 and I believe that this issue finally is fixed!
The OutputIntent has "Custom" added, but I believe that's no Problem (Quark did this also, AFAICR)
-
Has the team had any time to look at this yet?
-
-
1 minute ago, walt.farrell said:
You need to do it after creating the document, and you need to import it as a Document Palette.
Yes of course. But before I start working in the document, to save me from future frustration.
QuoteI don't think that will work as you want.
That's highly likely 🤣
-
32 minutes ago, Old Bruce said:
Global colours live in Document Palettes. If you don't first export and then import the Document Palette you won't have Global Colours. We can argue with, suggest a feature request to, the people at Affinity that it should be otherwise but right now it is what it is.
Well, if you open the example that I attached on the first post, you can see that the global colours can survive without a document palette! Check out the big triangle thingy, it has the colour "Globale Farbe 18". The same colour is used on the small triangle on the bottom right. You can "Edit global colour" and change both of them at the same time!
I agree that this may be not intended by Affinity, it may well be a bug of some sort.
-
34 minutes ago, walt.farrell said:
You must have a Document Palette (Add Document Palette, from the Swatches panel) before you can have Global Colors.
Actually, it looks like you can copy a global color (see above) but you can't get that swatch.
QuoteEven then, copying a Global Color from one document to another will not automatically get you a Global Color in the second document. You would need to add it to a Document Palette there, too.
Well, in my case it stays global as I made a few more duplicates of the shape and was able to change all their colours at once when editing the global colour via the colour panel.
QuoteFor larger projects, you could have a Template document with a Document Palette with your Global Colors defined, and start all your documents from that Template. Or you could Export a .afpalette file from your Document Palette, and Import it into your other documents.
I think importing a .afpalette before starting a new document will probably be what I'll do.
Importing the palette will not work with existing global swatches, they don't "link" automatically. So I will have to export the palette from the original design, and import that into every new file before copying the design into the new file (if I want to change the colours of the design in that new file). As long as the colours don't change (e.g. for the logo) it's probably not worth worrying about this.QuoteBut as you make changes in one document they won't be picked up in the other documents. Global is global only in a single document.
Yes, thats a bummer. Maybe exporting a new .afpalette and importing into an existing file might work?
(I see a notice that there has been a new reply in the time I took to compose this post (compost?)
so if it looks out of place blame me)
-
23 minutes ago, Old Bruce said:
I have no idea why the colours in your document have names. I also have no idea how you put them into the new document. The following description just confuses me. Did the v1 file have the global colours in a Document Palette? I assume you opened the v1 file in Publisher (whether v1 or v2 I don't know). How did you "drag" the (globally coloured(?)) objects into a new document?
Actucally I reproduced it just now with the latest APub on Win 10:
Open a new project, draw a shape, make a new document palette, add the shape's colour as a global colour, edit the name in the palette if you want.Then open another new project, don't close the first one. Copy and paste the shape from the first project into the new one. The shape will still use the global colour, but this colour will not show up in a document palette - there is none. But even if you make a new document palette before pasting the shape, the global colour won't be added to that palette.
I was wrong about drag-n-dropping, seems that does not work between document windows.
-
Thanks, both of you, I was just writing more about what I found out so I'll drop this here first before I answer your points.
I've noticed again that it's impossible to select more than one swatch at a time to turn them into global swatches 😭 This makes working with imported palettes a chore.
And to boot, I found that the swatches that were "created from document" seem to be LAB colours, and not the CMYK that was actually used in the document?! So it's creating a palette of swatches that are almost, but not quite, entirely unlike what's expected 😬
Can anyone confirm this?I think I really want linked palettes with global colour swatches. All the corporate colours of one client neatly in one palette, and quickly imported into a new project, and quickly updated when a new colour is introduced or an existing colour needs a change.
As I said before, I think the use of non-global swatches is very very limited. And it's a real bummer that linked / application palettes can't have global swatches.
-
I noticed that there's a menu option "Palette aus Dokument erstellen" (create palette from document). I chose this and then "create document palette". In the resulting palette the colours are all there but they are not linked to the objects, they are not global colours, they don't use the existing global colours' names.
IMHO that's not really helpful when working with bigger projects.
-
In the attached file are shapes that use global colours. The objects were originally made in ADesigner v1.x, later edited in the Designer Persona in APub and then
draggedcopy-and-pasted from existing files to new files.Now I see the names like "Globale Farbe 18" in the "Colour" tab, but I don't see them anywhere under the "swatches" tab.
Is there a way to have the existing global colours show up in a swatch palette?
-
Hi PE1, thanks for your help.
The bug is a bit different than what you have done:
In any print product, it may be that there are images that don't have the required dpi available. If that's the case, these images should not be automatically re-computed to fit the output dpi. Re-sampling will not make the quality better (unless maybe in the future there are improved "AI" algorithms at work).
So if I have a print job that requires 300 dpi, and some of my images have only 200 dpi at the size used, then I want these pictures to retain the "true" 200 dpi and not be artificially upscaled to 300dpi. The rest of the PDF should use 300dpi, e.g. for flattened transparency or other images that were 300 or more dpi. Down-sampling from (much) higher dpi is a good thing.
Hope it's clearer now what my problem was! -
Thanks for looking into this!
I understand the transparency getting flattened, but it's a bad habit to upsample lower dpi images. Downsampling from higher resolution makes sense, of course. Artificially raising the dpi (effectively inventing data that just isn't there) does not add any quality, it only makes the files bigger. IMHO this is a bug.
-
-
This has been very interesting to read! Thank you @Hangman, @PixelEngineer and @lacerto for showing a lot of the issues around PDF export with Affinity products. Have any of you seen some improvements in the newer versions?
-
Coming out of this discussion I noticed that when exporting to PDF/X-3, the checkbox "convert image colour spaces" has no effect on the result. Image colours will always be converted, whether the box is checked or not.
Is this a bug or is this by design?
In case it's by design, could you make it clear what's going to happen with the colours? Maybe having the box checked and greyed-out (inactive) would show that this will always apply?
If you change the box, please also do the same with the PDF/X-1a option. Right now, the box is disabled but unchecked there, which is giving the wrong impression that there won't be any conversion applied.
BUT I'd rather this is a bug and it would be possible to have RGB images alongside CMYK in PDF/X-3 files. ☺️
-
On 12/2/2023 at 4:47 PM, lacerto said:
Affinity apps convert images to CMYK when using PDF/X-3, no matter whether using the "Convert image color spaces" option or not (even if the images could stay in RGB color mode). This happens both in v1 and v2, and probably because PDF/X-3 does not allow live transparencies, and as Affinity apps do transparency flattening by rasterizing, Serif has obviously chosen to do CMYK conversion anyway (also for objects that do not contain transparencies).
Has this been reported as a bug yet? I couldn't find something like this on the forum.
If it's not a bug, I would ask Serif to disable the "convert color spaces" option on PDF/X-3, like it is with X-1a, so that the result does not come as a surprise.
(It would be even better if the greyed-out box was still showing a check mark, since the conversion is active and can't be switched off) -
I've got to correct myself from above: This does not happen with JPGs (unless you crop them the wrong way apparently). It only shows up when transparency is involved with PNG, TIFF, WEBP -- but interestingly not with GIF files. My test files are attached to the bug report.
-
Hi @NathanC thanks for looking into this.
I've now made a series of tests to reproduce the issue. The files are attached.
I was wrong about the issue showing up with JPGs. It only shows up when transparency is involved.
So I made a small graphic and saved it as PNG, WEBP, TIFF and GIF with transparency and for comparison as a PNG without transparency.
I dragged these into APub and resized the images so that they have a real resolution of about 148ppi.Then I exported the project to PDF using all the presets (PDF resolution 300dpi).
The issue only appears when exporting to PDF/X1a or PDF/X3.
Then the transparent images will be scaled up to 300dpi, with the exception of the non-transparent PNG and the GIF.Also interesting: If I leave the "change image colours" checkbox empty when exporting PDF/X3 the transparent PNG, WebP and Tiff will still be converted to CMYK! The GIF and the non-transparent PNG remain RGB.
-
@Callum Maybe it is only an issue for German language users??
I mean ÿ looks a lot like an german umlaut anyway... 😜
-
Thank you all for checking and confirming this!
I made a bug report atMore info on the issue:
the JPG images were just dragged onto the page and then resized to fit the large canvas. So no extra masking, nesting or cropping was done.
I couldn't check if it only happens with PDF/X yet. -
Latest APub on Win 10 x64
To reproduce:
The use case was a big banner to be viewed from a large distance. So make a project in a decent size, maybe 2m x 1m
Drag some (medium-res) images in and make them fit the big page.
Their actual resolution will be quite low (e.g. 40dpi)Export the project to PDF using a dpi that's higher than that of the images (e.g. 60dpi).
Check the resolution of the images in the resulting PDF:
What should have happened is, that things like transparencies are flattened using 60dpi resolution, and the images remain at their lower native resolution.But instead, the images will have been upscaled to the document resolution (here 60dpi)
That doesn't make sense to me, the upscaling is not really introducing better quality. It only increases the file size.Some people reported this only happens with PDF/X files, I did not have time to check this.
See also the original question posed in the forum:
-
Thanks for the conformation! Always good to know it's not just me going 🤪
IIRC, you're on a Mac? I'm on Windows, so it's not just a platform thing. I've got the language set to German, but last time around it wasn't clear if that was affecting the bug(s).
APub 2.2.1: Colour profile ISO coated v2 300% still does not export correctly to PDF
in V2 Bugs found on Windows
Posted
Hm, seems like I can't do that anyway...