dasigna

o.k. i do know, that desktop printers always are rgb. so for cmyk-proofing colors are emulated. otherwise we wouldnt need any rip-software and expensive calibration things ... so in my case the rip acts as a postscript printer that generates its own .ps-files for printing then. normal setting is to leave color conversion up to 'printer' and not to change cmyk-values - in every application. that is fu**** easy with also fu**** great results of 99,8% accuracy. so if i understand the answer of patrick correctly - affinity simply cant do this! right? so for affinity i have to output some .pdf print file and send this to the softrip via printing though acrobat ...? rip cant handle .pdfs directly - only its own .ps files (efi_express btw.) so in my understanding it would help already if color management through affinity simply would be deactivated automatically if one set 'leave color management up to printer' ... or even if it could be deactivated manually.

no? which way then? creating .pdfs and proof them, which doubles the amount of work? using a dedicated rip with calibrated printer and have to trick again - really? i have a document in cmyk. printer output should be possible with that... every other application i use can manage to print to a postscript printer and let it manage colors ... illustrator, indesign and even corel (!). in every program printer profile is then deactivated by default. works well and gives the expected results. (which then are even identical across all apps by the way...) why not affinity?? quite stunning! (if not weird)

use both - but not for printing. rip is registered as a printer and creates its own .ps-files. works with every native application just completely fine - except from affinity 😕

has anybody tried to proof a document with publisher? currently getting mad with this! having a dedicated rip i am trying to get an accurate proof out of affinity publisher with no effort. publisher seems not to be able to skip any color profile when printing - even when setting that colors are to be managed by printer, theres still a selection for a color profile that obviously interferes with the print and leads to wrong colors. is there ANY way to tell Publisher NOT to use any profile when printing to the rip???

... i would be glad to read this, but i fear there isnt one (convincing).

But its fundamental - isnt it?

basically - yes. but having it in a panel for constant view and control would be muuuch better! currently one has to click like mad just to control again... so why no dedicated panel??

Hmmm ... still relevant or not? IMHO - 'color manage the print' via printer (driver) settings isnt possible at all in any satisfying way. at least as long as you're within cymk. the only way is to go over a dedicated rip and profiled paper, assumed you want to achieve correct cmyk simulation. any other attempt via standard printer driver settings is simply trial and error with no chance at all to get proper results ever. this whole thing is some science of its own and not at all simple done :)

hi there, first of all - great software already. miles ahead of several other 1.x-versions in the past. joined the group of 'adobe-refugees' already in 2017 and waited long for this peace of software to get ripe. did some testing till now with several projects without daring to use it fully in production... now i did and immeadiately it gives me headaches. scenario: a brochure with about 20 pages and lots of ads. where everything that has to be done internally in APub works really well and flawlessly so far, the placing of external assets throws problems that let me question again if this is really usable for production yet ... first big trouble: embedded fonts in .pdf's! sometimes they work without hassle and the pdf looks as is expected - sometimes they dont work at all. for the latter one have to tweak every single ad to either convert the fonts or generate a bitmap out of it. thats completely weird. and to be honest: not acceptable at all. the amount of time this consumes is far too big and really can not provided at all. i dont want to have editable assets or ressources to be placed. they just should be placed - as they are. period. second big trouble: these ads come from all sources and theres no way to control what the author did/does. so the colors gives me another heavy headache! this time the issue extends to the edge of not being able to use APub for production ... colors get changed by APub!! obviously depending on the embedded (or not) color profile of the ads APub changes the colors!! what the hell? it seems, that if the embedded color profile of the ad is by chance the same as in the APub project, everything is o.k. - but for every other scenario they obviously change! why? astonishingly the colours are correct when trying to edit the ressource within APub - on leaving the edit theyre wrong again. sometimes that obviously, that the results are by far not acceptable anymore. how to explain this to a customer??? this time theres really no way to get it right - how should i change the icc profile of an external .pdf?? again going the weird way over a bitmap? whoah. just one simple question: why do ressources as pdf's have to be editable? take them as they are and simply ignore embedded profiles. // btw: i've put the same project together in ID simultaneously - no hassle at all. all ads fine, every font displayed correctly and same for colors! // so - where is that fu***ing "ignore enbedded color profiles" button in APub? where is the question-window when placing a ressource that asks for whether to simply place it or make it editable?? another thing: i am missing the ressources *panel* for constant control of missing or changed ressources. wheres the info panel to see what effective resolution a embedded ressource has, and which color profil is assigned, the original dimension etc. etc.? at this point my nerves are heavily strained and i am quite disappointed to see thats not working out. for such simple things ...! maybe someone might tell me i am doing something dead wrong, and its not APub? please.

just wondering what might be the benefit of more than 2 decimals (regarding mm) in a graphics app??? (set it to 2 and just works fine btw. ...) a watchmaker might use more - but not in affinity or similars ...

honestly, referring to such filesizes they wont bother me at all! getting much more interesting with bigger sizes, lets say 50 or 100kb up. more interesting what AD would do here (havent really tested yet, awaiting the promised preview-update with 1.6). so as long as the qualitys just fine some more kb are o.k. (to me). that spoken, the far more interesting part would be the files compared regarding quality (again, to me). concerning "making google speed insights happy": i dont give a damn about it as long as speaking of several tiny 5 or 10kb! :) speed insights anyway has to be treated as not very helpful more often than less. the results are regulary kind of... yes what? ... strange? as long as any website runs smooth without hassle under every condition, google might tell me whatever they want. so as long as its about 3 or 4kb for a file - forget about it. if its 10 for a 100kb file - ditto. (unless there aren't hundreds of them...) if theres a remarkable difference in quality - thats another thing. may it be possible to see what you've tested?

just as remark from my side... fireworks always supplied the smallest files so far - even unmatched by ps or illustrator. (insnt used by myself anyway, as 3.5 or 3.2 kb doesnt matter to me...) but as meb said - it may not be appropriate to compare in this way as you dont handle the files directly made by AD. seems it cant handle ps-files very well due to the mentioned reasons. would be interesting whats happening to quality and size if you would build them from scratch in AD (know this is not intended and extra work, but would be interesting anyway...) :)

... reading, reading again etc. maybe that might help. seems you can follow my demands as well as you dont? so it may be pointless to you - not for me. but thats o.k. in every way. thanks for being here. :huh:

... yes thats the fun side of it at the end ;) (forgot to mention).

... thought i have done that some way up from here ... no?

sometimes its kinda strange in here ... battle of words and such where no one is eighter completely wrong or right. and sometimes i have a strange kind of feeling that too many seem to be forced to defend affinity or serif wheres no need to. and the discussions over stability towards mac or windows are quite useless anyway. the thing is (just my two cents): if serif would claim to be only for the 'average' users or just for the fun stuff side and not charging anyone for anything, alright. but they dont. and even more as the software is claimed to be for professional use also - what would be any better for serif than those who uses this every day (if not for work), reporting issues and such? its kinda development stage for free and even getting paid themselves... ;) so yes - there are chrashes. and yes there are demands for new features. development has to be towards more reliability and enhancement of existing features as well as new features. hard job. but i hope they will manage it - last update already lead to much faster startup times e.g. - great. so dont damn those who want more features, nor those who are reporting issues or want more stability. btw. i want both :lol: so hopefully serif listens to all, sort things out and go for wise decisons. at the end (supposing) we all want the same: a good reason to ditch off the old bulls with confidence!

some words in english for all to read: really dont know whats the problem here :) the complete url is listed at the beginning of every chapter - what you are referring to in your photo is only the notice for the single file you need at that stage of the chapter, as theres no link to every single file. and you get all those files as .zip from the url mentioned before. complicated, huh? the actions are: reading - understanding - acting. vica versa is not that good ;) the only thing you are right to is the circumstance regarding the lack of 'https' in german edition as somewhere stated. in fact theres only 'http'. so hopefully at least i was able to bring you some light into the dark.

yeah - read that. so someone of the marketing people have to talk to those others finally and tell them what they have promised!! :blink:

... hmmm. always regarding the print file factor. but thats not what i'm after... its the way in between ...and yes, i know (has been mentioned) dealing with 16bit cmyks is obviously an pre 2000 behaviour :wacko: so this seems to be an argument anyway. but eighter way - it would be really poor if i would have to tick that point off. not even being able to handle lots of existing content aggravates the real change to affinity unnecessarily. cant imagine it would be this complicated or heavy labour to implement it.

any statement from dev side possible?

... or at least resize them to max screen when viewing. :) +1

just to be clear: "... I do not know any printing processes that take CMYK16." - nor do i . "... most people use RGB in the production and convert to CMYK8 at last stage." - obvious. but thats not the point. 1. you can go along with (pro-photo) 16bit rgb most of the way. right. best way. but at some point you have to change to cmyk - and that leads to the important thing: (at least me) never let any software handle this completly in an automated way! the results quite often are more or less not whats to be expected. no matter if generating the print files yourself with automated conversion from rgb to cmyk or even sending rgb within your files to the printers and let them do it. (btw: for the second one i do not know any printer who is giving any warranty in this case for perfect results...) 2. so you have to have control over this when going for cymk at the end, and occasionally (and possibly) have to tweak some things within your required colorspace (cymk) ... you cant do that in 8bit seriously due to the high risk of the limited colorspace and loosing information and other damages. you have the smaller cmyk colorspace anyway with 16bit, right, but you take advantage out of the much bigger headroom (just watch the histogram when editing photos in 8bit... regardless of colorspace). so going for 8bit is the very last step when compiling the final files for print. everything above that has to be 16bit - even in cymk. mandatory. maybe most of the people who are using cmyk for print havent noticed any issues so far (i had), or arent even aware of the limitations within 8bit cmyk (i am). so theres no way dismissing 16bit cmyk in a serious workflow for print at least for me - have to have this both in AP and AD. its simply all about control over the final result.

... they cant be 'saved' normally (at least here on windows) obviously due to copyright reasons (absolutely clear and o.k. with this) so you have to perform 'save as' anyway when tweaking with them. but 'wasting diskspace' shouldnt be any argument really with terrabyte-disks nowadays for a several MBs 'big' file B)

... why not simply take advantage of the 'save as' option and store them to a destination of your choice? as long as you remember this you'll find them again with no hassle :)

... are you kidding or do you know that this is the reason??? "for press only" ... what should that mean for a designer app that is intended to be "used by professionals" for "your professional workflow"? not to use it for press? sorry, but this really confuses me and i hope it cant be the real answer because this would say that there is no plan implementing it in an acceptabele amount of time - which would be another downpoint to me and my workflow for cmyk printing ... would love to hear something about this from the developers.