Jump to content


  • Content Count

  • Joined

  • Last visited

About dasigna

  • Rank

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

436 profile views
  1. 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 ou
  2. 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
  3. 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 😕
  4. 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???
  5. ... i would be glad to read this, but i fear there isnt one (convincing).
  6. 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??
  7. 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 :)
  8. 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 ques
  9. 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 ...
  10. 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
  11. 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...) :)
  12. ... 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:
  13. ... yes thats the fun side of it at the end ;) (forgot to mention).
  14. ... thought i have done that some way up from here ... no?
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.