CMYK tifs

I am a new customer coming from Aleyant (eDocbuilder).

I was told to post to this thread in order to stay on top of progress for CMYK capability.

My current vendor allows for backgrounds to be CMYK tifs, and the resulting production file contains the original tif with all CMYK values unaltered. I am also able to upload an RGB jpg to be used in the online designer that is not included in the final.

I plan on having multiple background from which the user can choose via clipart groups. While RTD does allow me to upload CMYK tifs, the onscreen representation of the file get severely butchered after color conversion. Will it be possible to, for example, to upload a cmyk tif backround and within the setting for that particular graphic, upload an "onscreen" rgb version that is used to designing only, and still get back the original CMYK tif in the final file?

My ideal solution would be to not use 'clipart' libraries, but to have a "CHOOSE BACKGROUND" button that is obvious to the user and stays at the top of the list, and is always on the bottom layer.

For an example of what I am referencing, see the following link showing my "Christmas Themes" for realtors, where they can choose from 7 backgrounds:
http://www.designmycandybox.com/real-estate-agents/119-holidaychristmas-themes.html


Greg Beckemeier
www.DesignMyCandyBox.com
(636) 542-8560



Edited 1 time(s). Last edit at 12/15/2015 01:49PM by candycartons.

Update. I noticed you can designate different backgrounds at the 'product' level and have them easily swapable by the end user in the designer. AWESOME! Way better than trying to utilize the clipart groups.

My question/need: Can each designated background have 2 files associated with it, one CMYK for the production download and one RGB for the onscreen representation?

Hey Greg, welcome in!

1st, about the status of the "onscreen" cliparts (I'm making a quick sum for other readers).
In the RTD there are 3 physical files stored when you upload a clipart.
1st is he original clipart itself, which will be used for real only and exclusively in hi-res generation processes
2nd is a PNG conversion of the clipart, max size 800x800px. That's the clipart used in the designer, so the one that user actually see onscreen
3rd is a simple 425x425px thumb version used mostly in the clipart browser.

Right now, when editing a clipart, it is already possible to overwrite the existing thunb clipart.
The idea being discussed here is to allow also the editability of the onscreen version.
Result would be to upload an RGB clipart that looks good enough on screen, knowing that the original one used in hi-res process will NOT be the same file.

That said, about the status:
very recently we've added some extra controls on custom cliparts in the orders page, to check the ytyep/colorspace/recolors/etc...
All of this caused some minor issues, fixes of which we're beta-testing right now.
That process is very strictly related with some internal checks I wanted to apply also for this new edit feature, so we're extremely close.
I think I will be able to release it before Christmas for sure.

HOWEVER THERE'S ONE THING TO KEEP IN MIND:
When you generate the hi-res file in your admin panel (IE, creating the production file), it is ture that the RTD will make use of your original file: however, it will still force the conversion of the colorspace to RGB.
The reason right now is pure legacy: as end users designs on an RGB device (monitor), we decided to keep everything RGB based (you probably noticed this also when you define color, for example).
This could change in future, but for now I just want to state clear that the file you'll get will not preserve your colorspace if it's not RGB

And finally about the background: just to be sure on used terminology, what exactky are you using?
It sounds like you're talking aobut multi-BG images. but in that case I'm confused because BG images are NOT being exported in the hi-res at all. They're meant to be pure decoration representing the products, and 99% of times they're not even the best choice (now I surely prefer to play with BG/FG and BGcolor masks)

That's all I have for now!

Thanks for the feedback, Mark =).

RGB is not a good fit for my workflow. My backgrounds which include a lot of gradations and rich black simply print best when I have strict control over the CMYK. Converting from CMYK to RGB and back to CMYK is, unfortunately, a nightmare when printing the final product. When I have a gradation that starts at 100,0,0,100 and fades to solid cyan toner (100,0,0,0) it is a gorgeous final print. Taking it to RGB and back wrecks the colors completely and the final print is far from the intended look.

I was told from the outset that CMYK would be supported. I specifically asked "If I use a CMYK tif as the background, can I have the exact CMYK tif when the final file is rendered?" I was told that not only could I do that, I would be able to upload an RGB version of the background for the online designer.

My current vendor supports this beautifully. I can even set cymk color palettes for text, and will get those exact CMYK values when rendering the final. The only RGB elements are customer-uploaded photos and logos, which I convert to GRACOL before printing.

I wish I had the knowledge to switch to a total RGB workflow, but I don't. I have a new Xerox C60 light production press on the way and it supposedly should handle RGB elements well.

IMHO, any color converting of the original templates is a major no-no. It sounds like if I even commit to RGB graphics, that they still go through a color conversion prior to downloading the production file?

I get that this is the web. And, that is why with my current vendor they support uploading an RGB version AND a CMYK version of the major elements and backgrounds. That way, when I go to print, I know I'm going to get exactly what I had intended.

That said, I was planning on using the multiple backgrounds product option because I LOVE the background chooser within the designer. And, users can't accidentally send an element BEHIND the background and wonder where it went. But, now that you say the backgrounds are not included in the final pdf, this becomes a non-option for me.

Here is a link to my Christmas theme favor boxes, in which I want the user to be able to intuitively choose from 7 background options:http://designer.realtimedesigner.com/designmycandybox/index.php&tng=Y3BpPTc2NDc1

If I use clipart to accomplish this, then it becomes a layer on the left had column and hence is not obvious and intuitive to the user. Also, if I lock the clipart to background images, then the main clipart button on the top row is also locked. And, if the background is a clipart selection, users can accidentally send elements behind the background layer, causing confusion.

The main reason I switched to RTD is so my customers can save designs for later editing and reordering via the woocommerce plugin. And, I found the user interface superior to my current vendor's. But, these CMYK issues may not work for me.

I hope I'm not sounding like a jerk. I really do. But it seems to me that this engine, while AWESOME for screen printers and wide format, may not be a good fit for those of us who print paper product on toner based machines.

Is there any way we could talk, so I can show you my product and exactly what I am looking to do? All this typing takes quite a while =/.

Greg Beckemeier
www.DesignMyCandyBox.com
(636) 542-8560



Edited 1 time(s). Last edit at 12/15/2015 07:50PM by candycartons.

Greg,

Well, 1st small note: this is Alex, not Mark
I am the developer and this forum is where 90% of the RTD you see today had been created, thanks to user inputs.

I am not familiar with your product type, just as we were not with a lot of others.
So, do not assume that what does not exist now is to be considered missed: it is common practice here to discuss new features to match end user needs.
In short, the RTD is not a tool built by developers "guessing" what the industry might need: it's built with the industry itself, and it evolves on a daily base thanks to its own users.

Your scenario re-opens some interesting discussion we had in past, about the creation of a CMYK print file.
Technically it could be done (almost) easily, although there are several aspects to consider.

1st I can think at, for instance, are text colors: right now in the RTD you define them as RGB.
Fast solution would be, for hi-res, to force a best-guess CMYK conversion of those colors. But this COULD product unexpected results expecially in case of near-spot colors
Best solution would be to have a side table hwere you can define both RGB and CMYK values (web and printer, at the end): but this would surely require far more time, because of the needed data handlers.

But if we think at trying the best-guess for defined RGB colors, then what I can do is to force a different colorspace for the hi-res: just as now I'm forcing all RGB (no matter the viasual risks), I could try to do the same for CMYK. In that case, what originally is CMYK would just stay CMYK.
That would be obviously experimental initially, and would need a... tester.

So the question is: if I'd try to apply some of these tests, would you agree to side the developement by testing the results step-by-step?
If so, then we'll have to arrange a way to have a meeting to define this thing. I am positive it would be a very nice addition also for the RTD in general.

Let me know!

Alex

Crap. Sorry Alex.

I would be honored to be the guinea pig. The RTD interface is so far beyond the competition it's amazing. But, I completely agree that by supporting CMYK you would be able to bring in many more clients like myself who design in CMYK for their specific production machines. Even if the solution is as simple as swapping in a production CMYK tif to replace the RGB version of the background prior to file generation.

I have been testing on my xerox for hours tonight, toying with the idea of designing in RGB and completely abandoning CMYK. I have yet to get an acceptable print when sending RGB values to the xerox. Colors are washed out like crazy. My CMYK files print bright and saturated and glossy.

I look forward to speaking with you. I'm eager to get started and have my new store up and running so I can ditch my previous vendor and give my customers a better experience.

My number is 636.542.8560. Call anytime, day or night.

Greg

Greg,

better to use some different channel.
I suggest you to NEVER tell me to call anytime: I really might call you at 3am

To keep track of everything, I normally prefer to use something we can use as a reference point, like a ticket.
For this, would you mind to open a support ticket from your RTD admin panel (it's in the "Get Help & Support Options" tab)?

As subject just put "Candybox for Alex", and I'll get in touch there to discuss meeting options.

We should probably keep using this thread as well to let everyone know about our progresses: after some initial testing, I'm pretty sure we will want to verify the flow on a larger scale.

It will be interesting and fun!

Alex

3am is fine. I love my product as much as you love yours! =)

I realize now that Mark told me to open a ticket to begin with. I screwed up and posted in the forum. Sorry =/.

I honestly believe that once my site goes live, it will be a GREAT sample to show prospective print shops to bring them on board. Especially for biz cards, brochures, thankyou cards, invites, etc...

I will open the ticket now.

Greg



Edited 1 time(s). Last edit at 12/15/2015 09:16PM by candycartons.

Hi Greg. Welcome to this forum. I would like to chime in, now that you've made yourself pubic. It's always such a pleasure to see someone take the designer in a new directions as you've done. Great job. We will be following this cmyk experiment with great interest.

Thank you kindly for the nice note =).

I am excited to be a new customer. The service so far is, for lack of a better term, perfect! With my previous vendor, requests for engine tweaking would go into a holding tank and you'd be lucky if it was implemented within 6 months, if at all!

My goal is simple: to make it easy for my customers to get a great looking candy box. This means a user interface that is simple, effective and pleasurable to use.

After speaking with a local color expert here in St. Louis, he believes that if I were to switch my color workflow to solid RGB and let the rip handle the final CMYK conversion that I would be happy. No, I can't control toner coverage perfectly, but I may be splitting hairs. My trained eye is a lot more anal than my customer's requirements. They are happy to see their logo on a custom box and are less worried about color accuracy. If I were making boxes for a corporate level account well then it's a different ballgame as they typically require very tight color tolerances.

I'm curious as to the interest level from other users to have accurate CMYK production files that match the CMYK original graphics/backgrounds, as well as the ability to have color palettes with CMYK values for text. I don't want to put Alex through a bunch of work if the demand is not there. But, again, most paper printers across the country will design in CMYK and will demand that the final file have the original CMYK elements unchanged (ie. the background graphics of the document that customer is placing elements on top of).