Vector format for BG/FG Images - Registration Marks

Howdy!

Another new thing released.
First of all, a note: in case you don't know (or would like to understand better) what Background/Foreground images are in RTD, I strongly suggest to look at our new video describing them, here:
http://www.youtube.com/watch?v=U_E5yZe7pEQ
It's very clear and will let you fully understand how BG/FG images can be extremely effective to create very nice designer's layout.

The new feature:
It is now possible to feed also PDF and EPS files to be Background or Foreground images for fixed sizes, in the Sides Prefs area.
If a vector is there, an includes vector version link will be shown, to allow you seeing the vector itself.
No matter which format you'll upload, that vector will always be converted into a PDF.
I decided to do this because PDF is in any case the main vector format used internally by the RTD, so it was just senseful to have it since the very beginning here.

From the designer's point of view, nothing will change: users will still see only the image converted in PNG format as usual.
Where it will have an effect is when you'll create the Hi-Res vector file for an order.
As both BG and FG were initially meant to be only aesthetic addons for designer, previously it was not possible to include them in vector download (because they were not meant to be printed).
Now the Include BGImages (if any)? toggle is available also for vectors.

What happens if you set it to YES?
If the BG/FG files you provided are regular raster images, they will be used "as is". So, really nothing much useful.
But if you provided a vector format for BG/FG, then that vector will be used instead. And here things may be interesting.
There may be other applications as well, but the one we had in mind was to allow precise positioning of registration marks.
If you upload a vector with your registration marks as BG image, and then a regular FG to "hide it" to use in designer, you'll be able to obtain from your admin panel a vector file which will include both: just remove the FG image layer, and you'll have your final vector ready to edit, but with prcise registration marks already applied.

I am sorry if I wasn't too clear, unfortunately I am a developer and not a printer...
Hopefully Mark will jump in soon explaining that in some better way.

Enjoy!

Not really much to add...

A vector background can contain CUT LINES and REGISTRATION MARKS, which can be hidden from the user by the foreground image.

A similar effect can be created by putting cut lines or registration marks in your clipart, but by allowing the same in BG & FG, you can have a lot more flexibility.

Good job Alex!

Mark

CUT LINES - now that's what I'm talkin about. Great idea! Thanks.

Very cool.

This really adds a lot of value to the RTD system. We can almost download a file and have it ready to print without any additional work.

When you have a few thousand files to work with it becomes really time consuming. Anything RTD can do to save clients time is much appreciated. The only other thing that would make this feature better is automatic color fill for the vector file so that when we download the customers file it's ready to go. We currently have to manually set the fill color for every order.

This could potentially be done in two different manners.
ONE: when the customer clicks the color they want 2 functions happen. One the background color changes (as normal) and the vector file fill color changes.
TWO: everything stays the same as it is now but when the vector file renders during download on the admin end it captures the fill color information and fills the vector fill color.

I am sure there is more to it than that but I'm certain it could be done.

RTD is on their way to a fully automated system. There are RIP systems and printers out there that will automate their printing functions based on hot folders and auto nesting. Perhaps RTD will the future be able to provide an automatic file storage location for orders. Each product/file could be saved to a predefined location based on product. That way we (RTD clients) wouldn't need to download every file.

Thanks for the nice comment, Nate.

Fortunately the RTD base is strong, so as long as technology will advance, new and more powerful features can be added in time.
The problem for vector recolor is, unfortunately, still waiting for a suitable technology to appear.
I'd like to explain you the reasons, perhaps you may know some solution I'm not awared about yet!
So...

RTD from customers point of view has to work in browsers. This means it's basically a tool that uses scripting to place different graphical items in a design area, and that such graphical items are raster files. So, a pixel-based drawing tool.
When you ask for a vector output, RTD has to "convert" the used raster commands into vector ones. This is not always possible because of the very different nature of the two systems.
For example, this is the reason for which distortions you can use in designer cannot be automatically replicated as vector. I wrote my own pixel-level functions to create some effects, but the same math cannot work with vectors. However, what we decided in past was to consider this acceptable: cons is RTD clients needs to edit the vector to "recreate" some effects, but pros is the ability of providing final customers various tools/effects that couldn't be there otherwise.

Recolor is a similar beast. RTD can recolor what it can edit in some way.
While in designer, RTD is not recoloring your original vector clipart, but a separate rasterized version used for designer itself.
Vector is actually used only when the hi-res generation is invoked, and there's where the issue occours.
For SVG files a simple string replace is enough because it's basically a markup file, not binary.
Infact, recolor in vector IS actually supported for SVG cliparts.
But the main formats used as vectors by RTD clients are EPS and, internally to the RTD, PDF.
Both of them are binary files, and I wasn't still able to find any (decent) tool allowing me to replace a color into a PDF document. For this reason, you're not getting recolored version when you download the hi-res.

As you can guess, I'm more than open to suggestions. This recolor issue is really technical.
To simplify everything, what we're all waiting/looking for is a linux commandline tool that can do precise color replacements in EPS/PDF files. The day we'll find something usable, this issue will be no more.
If you know about any similar tool that could be used.... I think the entire community here will be all ears!

However, let me know if you have any extra thought after the quick explanation I provided.
Involving end users of the tool (you) in the developement process is the best way I can think at to create, in time, the best system ever.
So, thanks a lot for jumping in, will wait to see more from you!

Perhaps SVG and/or HTML5 Canvas could work in the background until older browsers catch up. This of course wouldn't provide the intended results for orders from customers who use older browsers but having something in place would help out a little. That way when most customers are using more modern browsers RTD will already have something in place and can bring SVG or HTML5 Canvas to work in the foreground instead of behind the scenes.

If RTD clients uploaded an svg file the color could then be changed dynamically through html or CSS No?

For those who dont know about SVG or HTML5 Canvas feel free to review the following:
http://dev.opera.com/articles/view/svg-or-canvas-choosing-between-the-two/
http://sketchpad.io/sketch/?newfile#
http://www.w3schools.com/svg/svg_examples.asp

Nate,

Canvas, HTML5 and SVG would all be designer-oriented stuffs.
But here the issue we were talking about was different: it's not about how to recolor in designer (which is already possible), but how to recreate the same recoloring when generating vectors for received orders.

However, even if it's a different matter but as you mentioned it, let me add something about SVG in HTML5.
There are some big drawbacks I've always experienced with SVG files.
As they're basically markup languages, there's the risk that different viewers (browsers) will not render them in the same way. This, if applied to designer where you expect customer to visually create exactly what he wants, is not something that can be accepted.
What I noticed is that results may be VERY different in different browsers: some do not support certain features at all, some other renders the same feature in different ways... the most common one is about issues with the fill area and linestyle.
This without mentioning how creation tools works: I always had big problems with SVG files create by CorelDraw, for example.
Till the status is so uncertain, there's no way we can even think at using SVG as the main format for the system. The good thing about rasters is that "pixels are pixels", so what's visible is known and certain.

For this reason, I'm not sure the day SVG can be used flawlessly is too close yet. As we're talking about the designer, we can't expect to use it natively till we'll be 101% sure that all used browsers will render the same way.
As a "last but not least" thing there are also some of the effects I mentioned in my previous reply: as said, they're pixel level ones. Switching to SVG in designer would also mean to lose most of them.

This is not to say I'm close about making RTD a fully HTML5+SVG tool in future. But I want to be clear about everything around it, because from a developer's perspective I will have to take into account every possible scenario.

Alex,

Makes perfect sense.
If Internet Explorer would just die then these problems wouldn't be as big of an issue.

Keep in mind that the variation in browsers is more controllable than the variation in color representation. Pixels may be pixels but what one customers sees on their screen probably displays differently than someone else.

Of course if an effect can't be done in a particular browser then that browser could then default to the old design tool method.
Different design tool for different browser settings.

Someday HTML5 and SVG will be common place. Its nice to hear that RTD is open minded about changes and willing to change when needed.

For now I'll have to keep my eyes peeled for a solution.

Best -

Nate

Nate,

In any case, I don't really see that as an issue now.
I mean, we're not talking about being able to do something in the designer which is not possible now: in some way, it's the exact opposite.
Personally, the fact that everything is moving to HTML5 and SVG does not automatically mean we will havo to run to follow the trend: at the end, what we all want and need is a tool that works. Keeping itself updated to the new technologies, but mainly that works. And RTD works, for now. Coding a parallel version would be a coding nightmare, also implying tons of possible sub-issues.
My main way would be to start updating "pieces" to newer versions as long as the needed technologies will be widely supported.

But now I'd like to bring this discussion back to the original topic, to avoid confusion.
If you'd like to discuss more about possible future plans at designer level like HTML5 support, feel free to open a new topic any moment. We faced the discussion other times in past, as for example here.

Please help me understand.

The Add Shapes, and Clip Art features are vector based graphics and those colors can be changed in the design tool.
I imagine those shapes are pulled from a database or server somewhere.

Why couldn't products work the same way? We would upload our own shapes to a database or server and the design tool pulls in that vector shape when requested by the customer. The only difference from Add Shapes and Clip art would be the product would have a locked position and cannot be moved or deleted.

I see some confusion on terms here.
What do you mean by "products"?
In RTD, a "product" is the entire set of definition and setting that creates a full product (including features, pricing, sizes, etc...)
But I assume you meant the BG/FG images that are the matter of this topic.

In that case, please note that shapes and cliparts are NOT the same thing at all.
Shapes are purely geometric objects: cliparts may be both vector and raster images, even uploaded by end users.

Also, designer's view and order Vector generation are completely different things as well. It seems to me you're mixing them in your posts, but understanding that pure vectors will NEVER be part of the game while in designer (which is customer's interface) is extremely important. In designer there will ALWAYS be raster conversions only, to ensure the final customer's experience.
Vectors are related exclusively to the creation of hi-res vectors for received orders.

Now: what we allow for BG/FG are images. What's new now is you can upload also vectors there, but still they could also be raster (we're not limiting that). What's totally unclear to me is what you mean with your post... seems like you're now talking about recoloring the BG/FG images?!?!? This because they're not (and will never be) meant to be recolored at any level. BG/FG are NOT meant to be part of the active design. They're normally decorative things, that you can now eventually use for other tasks as well.

The ability of using those to have references like Cut Lines or Registration Marks is a possibility you have thanks to this flexible setup, so in general you should first focus very well what you want to obtain as a final result, and then play accordingly with the various available tool to find the best solution.
The master rule in RTD is generally "do not trust how tools are named, trust what they do"

Regarding "pulling in" products, we call it loading a product because there's so much more than just an image... unlike the simple flash designers, each product in rtd contains a huge array of setup variables - bg colors, fg colors, which fonts and clipart to use, which tools are active, pricing tables.... while text, shape and clipart elements are basically just images. So changing a product is nothing like changing an image within RTD.

I understand that clip art and and shapes are not the same thing as a product.
SVG files are also purely geometric objects.

What I don't understand is that I can add a clip art shape into the design tool and customize the colors, shape and size.
Why couldn't a oval decal product work the same way? The clip art vectors obviously work in the design tool. I see it working on my end.

If a vector could be added to a product in the design tool then why couldn't the design tool be based on a vector shape to start with?

I don't think we're on the same page.

I'll have to call someone for a simplified explanation.

Quote
Nate
If a vector could be added to a product in the design tool then why couldn't the design tool be based on a vector shape to start with?

Couldn't? But it can!
I don't know how far you went in the RTD yet, but to me what you're saying seems exactly the matter of this announce.
BG/FG images are the only graphical component of a product, and they can be anything: ovals, mugs, complex shapes, etc...
Having an oval as BG and/or FG image for a product visually makes it an oval to design on (or "start with" ), I think.
And just like cliparts, even those images can now be vectors.

You don't think we're on the same page, and I have to agree: at this point, I cannot really understand what the main topic is.

I am a developer, so it's my "duty" to be extremely precise in terms.
As a regular user of the system you're normally not required to, but when you start talking technical to a developer, you need to be as precise as possible too, because I can have no margins: I have to consider all possibilities and scenarios, but I cannot guess yours.

For example, even if it's a bit OT but fine to explain what I mean:
Your first post was about vector file fill color changes. My reply was about different issues with specific formats. But your assumption was the possiblity of changing a fill color assuming the file is always a true vector. Now...

I claimed that Shapes are purely geometric objects, and I confirm now that they're the ONLY purely geometric objects you can find in RTD. This because RTD draws them internally, not grabbing them from anywhere. Just math. They always are pure vectors
You said that SVG files are also purely geometric objects: that's not always true, and they're not always pure vectors.
By using base64 encoded data, you can embed a raster image into an SVG, and you can do the same on any other common format. Even EPS and PDF files may contain also raster informations.

So, thinking user, it's fine to think at vector formats as vectors: but thinking developer, you cannot assume they'll always be pure vectors, because it's technically possible they'll be not. Even if only 0,01% of vectors may include rasters, I have to consider it because it's a possible scenario, no matter who will face it.
That's why when you move away from the user point of view and you start discussing at "developer side" an extreme precision in terms is needed.

SVG is not the best in my opinion Alex. Hi, by the way!

SVG, as Alex said, does not always contain just vectors. Also, it does very poorly with detailed elements. Love seeing these improvements. RTD has come a long way from all the contributions and hours we spent lol.

SVG is not the best in my opinion Alex. Hi, by the way!

SVG, as Alex said, does not always contain just vectors. Also, it does very poorly with detailed elements. Love seeing these improvements. RTD has come a long way from all the contributions and hours we spent lol.

I understand all of this and comprehend what is being said.

I am only talking about product creation from the RTD client side not the customer side.
I have control and know when a raster is involved in my svg file.

For instance. I want to create a new product for my customers to design on. I don't want to use a raster image for my backgrounds but rather a vector file. So when I upload my file for FG or BG I only upload one file (a vector file).

In one of your previous posts you said that the Design Tool wont allow for that.
But I see examples of clip art and images using vector based designs all the time. If the design tool can't handle vector files then why can I add them through the clip art feature as a customer?

Something doesn't add up.

I see what you want to do, and that's precisely what this thread is about.
The Backgrounds/Foreground images can be set in
PRODUCT OPTIONS => Configure Sizes => FIXED SIZES => VIEW FIXED SIZES EXTRA OPTIONS => Sides prefs.
In past only raster files was possible.
Now it possible to feed also vector files in there (EPS preferred)
So yes, you have to upload only one file. The needed raster conversion to show it in the desginer will be done by RTD internally.

Nate - check out this video on MARGINS... it also discusses where to set the size of your BG/FG images - by entering the size of your photo (mine was 32inches) you can force the output to be the proper size.

http://www.youtube.com/watch?v=O11Bjo3RVXk&feature=youtu.be

Hope this helps.

Mark Sr.