Force text wrap for text elements

I had been asked a couple times how to solve the "paste issue", which means when users copy/paste from other applications like Word, Excel & Co.

Normally, the RTD wraps correctly when there are "real" newlines in the pasted text.
But when copying from applications, technically text is really all in a single line, just wrapped into the screen by the application itself.
In those scenarios, what happens is customers copy a text that LOOKS on multiple lines, but really is not.
And, when pasting into the RTD, the text is rendered as is, which means a single line. Of course this results in an unreadable super tiny text image.

To help on this, if this is an issue for your specific product line, there's a small hack you can apply.
In your RTD admin panel, go in SYSTEM OPTIONS => Configure Store layouts and, on the dropdown on top (the "Edit Store" one), select the store you want to alter the text behavior for.

-------------------------------- IMPORTANT EDIT ----------------------------

Following this discussion we ended up creating new functions in the RTD itself, which now forces a grand default value of 120 max chars per line.
I removed my original post up to avoid confusion, so consider only this new block as the one you should use to make this work.
In the FOOTER CODE FOR DESIGNER, instead of pasting the code of the attached file, simply put this:

<script>
DelayedTextUpdate_Set_MaxCharsPerLine = (function() {
	var cached_function = DelayedTextUpdate_Set_MaxCharsPerLine;
	return function() {
		var local_custom_textwrap_offset = 80;
		return local_custom_textwrap_offset;
	};
}());
</script>

This block allows you to determine which the max number of chars per line should be.
In this example we're simply setting it to a fixed value of 80, but you can programmatically make it more complex to match other scenarios.
So, for example, the ratio-based example posted below should be written like this:

<script>
DelayedTextUpdate_Set_MaxCharsPerLine = (function() {
	var cached_function = DelayedTextUpdate_Set_MaxCharsPerLine;
	return function() {
		var local_custom_textwrap_offset = 40; // this is the default, just in case we'll match nothing else
	
		var local_actual_w = document.getElementById('im_size_w').value;
		var local_actual_h = document.getElementById('im_size_h').value;
		var local_ratio = local_actual_w/local_actual_h;
		if (local_ratio<=0.6) local_custom_textwrap_offset = 10; // near or below 0.5, very tall
		if (local_ratio>=0.6 && local_ratio<0.8) local_custom_textwrap_offset = 20; // near 0.7, normal portrait
		if (local_ratio>=0.8 && local_ratio<1.2) local_custom_textwrap_offset = 30; // near 1, almost square
		if (local_ratio>=1.2 && local_ratio<1.8) local_custom_textwrap_offset = 40; // near 1.5, normal landscape
		if (local_ratio>=1.8) local_custom_textwrap_offset = 50; // near or above 2, very wide
		
		return local_custom_textwrap_offset;
	};
}());
</script>

Edited 3 time(s). Last edit at 04/08/2015 03:59AM by Alex.

This is a good start, but how will we cope with all the hugely differently-sized items we have?

We have everything from tiny 3"x1" tags to huge 24"x48" signs. Some are fixed, some are ranged.

We need to be able to configure the character wrap limit to reasonably accommodate each size flexibly, or customers will complain.

If I am not reading your solution correctly, and this can be applied to different items of different sizes, please let me know.

Well, the code I pasted is general and would affect all texts in all items/sizes.
But it's code, and this means you can add conditions to determine the limit.
The relevant part, as said, is this line:

var local_custom_textwrap_offset = 40;

Now: the RTD has IDs for products: they can be seen in PRODUCT OPTIONS => Manage/Define Products.
When you select a category and the list of avail products appears, the first column (named "Int. ID") is the product ID.
The currently selected one is available in the designer as a global JS variable named product_id

There are also 2 IDs in the designer, named im_size_w and im_size_h, which are the currently selected sizes in inches, as defined in your setup.
All this together can be used to create your conditions. Something like this:

var local_custom_textwrap_offset = 40;
var local_actual_w = document.getElementById('im_size_w').value;
var local_actual_h = document.getElementById('im_size_h').value;
if (product_id==12345) local_custom_textwrap_offset = 30;
if (product_id==67890 && local_actual_w<=40) local_custom_textwrap_offset = 20;
etc....

As you can see, the idea is to define first a DEFAULT value of 40.
Then depending which product/size we have in that moment, apply variations.
In my example, I'm simply saying:
if the product is the one with ID 12345, use 30
if the product is the one with ID 67890 and the width is less or equal than 40 inches, use 30

This is just a basic idea on what you could do and can surely be expanded to something more complete and complex.
Hope this makes sense!

So will we have to include -every- item in this? How will it deal with portrait/landscape variations?

I want to clarify before we begin thinking about our items.

Would be easier if coded as part of the RTD itself, which could happen in future. But as of now yes, if you want an immediate solution, you will have to code them all unless they'll be fine with the default value.

For portrait/landscape it will change nothing because when you switch, var local_actual_w and var local_actual_h are simply swapped.
So, in this exception's code, you should just add "if"s just as if they were standaone sizes.

Another possibility could be to play by aspect ratios, and define values based on the result of var local_actual_w / var local_actual_h.
If you know how many chars you want to allow based on "how wide" or "how tall" the designable area is, aspect ratio could help.
Like this, for example:

var local_actual_w = document.getElementById('im_size_w').value;
var local_actual_h = document.getElementById('im_size_h').value;
var local_ratio = local_actual_w/local_actual_h;
if (local_ratio<=0.6) local_custom_textwrap_offset = 10; // near or below 0.5, very tall
if (local_ratio>=0.6 && local_ratio<0.8) local_custom_textwrap_offset = 20; // near 0.7, normal portrait
if (local_ratio>=0.8 && local_ratio<1.2) local_custom_textwrap_offset = 30; // near 1, almost square
if (local_ratio>=1.2 && local_ratio<1.8) local_custom_textwrap_offset = 40; // near 1.5, normal landscape
if (local_ratio>=1.8) local_custom_textwrap_offset = 50; // near or above 2, very wide

I copied and pasted this into the footer section and all the code showed up on the bottom of the RTD.

I did not alter anything in the code.

I checked your designer, but I do not see the code exposed. Have you changed anything after posting your reply?
Normally code is visible if you forgot to embed it into <script></script> tags.

One other thing I noticed is the misplace of the code checking the current size. As it's code, perhaps I should had been more clear.
Size check should be performed everytime the function is needed. So, better if it is a standalone function itself.
Please consider the attached version instead.
With this, the only place you need to put your check in is within the Local_Custom_Checksize function.

Right now I made it simple to always return 40, like this:

function Local_Custom_Checksize() {
	var local_custom_textwrap_offset = 40;
	return local_custom_textwrap_offset;
}

So, if you want to try my sample based on ratios, the function needs to be rewritten like this:

function Local_Custom_Checksize() {
	var local_custom_textwrap_offset = 40; // this is the default, just in case we'll match nothing else
	
	var local_actual_w = document.getElementById('im_size_w').value;
	var local_actual_h = document.getElementById('im_size_h').value;
	var local_ratio = local_actual_w/local_actual_h;
	if (local_ratio<=0.6) local_custom_textwrap_offset = 10; // near or below 0.5, very tall
	if (local_ratio>=0.6 && local_ratio<0.8) local_custom_textwrap_offset = 20; // near 0.7, normal portrait
	if (local_ratio>=0.8 && local_ratio<1.2) local_custom_textwrap_offset = 30; // near 1, almost square
	if (local_ratio>=1.2 && local_ratio<1.8) local_custom_textwrap_offset = 40; // near 1.5, normal landscape
	if (local_ratio>=1.8) local_custom_textwrap_offset = 50; // near or above 2, very wide
	
	return local_custom_textwrap_offset;
}

Would like to say this is a really great addition to rtd. Works perfectly for our purposes in Alex's last posting for default 40 with variable ratios. I can see this being standard in rtd code. Needed for years. Can't tell you how many times the lack of text wrap has surfaced support calls.

I always amazed when these things come up and we haven't mentioned them previously. A huge thank you to JessicaPM for suggesting this topic. It's because of users voice in this forum and rtd's fast response that things get done.

I am thinking at how to best make this a default code in the RTD as well.
As an initial implementation, I think I could place all the functions right in the main code, so that users can "hack" the default values by altering only the Local_Custom_Checksize.
But default would be to force a max value, like the 40 I used above.

Main problem first is to determine which value should be the big default for the whole RTD.
I cannot imagine many scenarios, but if I put 40 as default, this means that no one in the RTD will be able to enter a textlione composed by more than 40 characters unless they will apply also an hack.
So, based on your experience with both small and big prints: which could be a safe value that would not cause issues even in the biggest print you can technically imagine?

We will try this, but keep in mind, I have very little experience with this kind of coding. I know a little CSS and HTML.

Another concern we have is changing the font size dynamically, not with stretching the text boxes. Our customers often copy and paste and will want to change individual parts of the pasted text.

Is this also possible? There seems to be no way for the customer to change the size of the text and keep the same size text box with text wrapping. I am afraid our customers will get frustrated if they cannot adjust it easily. A lot of customers submit orders with long articles, poems, song lyrics, instructions, etc.

Attached please find some typical examples of text that needs to be easily changeable. Please note the names have been blurred for privacy reasons. I included the bamboo diamond to show graphical placement and wonder how this will affect the script.

I know the current method is to probably make customers create many text boxes, but I wanted some examples to show you what problems we fear people will run into with the text wrapping, font sizes, and faces.

I appreciate trying to find a solution to this problem!



Edited 1 time(s). Last edit at 04/07/2015 09:03AM by JessicaPM.

I see and understand your issue, but this time I do have bad news: we don't have a solution for this.
There's no way in the RTD of chaging style/size of text portions only. Only way, as you already correctly pointed out, is to use multiple text entries.

Only other way I could think at would be to import in the RTD, instead of texts, an image. But this would mean your customers should first export from their text editor as an image (typical case, exporting an openoffice document as PDF).

Sorry about this.

As far as a safe character count, most larger signs are in a landscape format and an average sentence is 50-60 characters. 50 would probably be okay to test with.

Doing a few "what ifs" I think something in the range of 60-70 could be the default. It's a tough one to figure as there are so many situations. Just a thought here, but would it be crazy to place a user accessible variable right on the text pandisplay? XX characters per line? Or perhaps a slider to dynamically adjust? I like that last idea.

Cos,

giving this as an oppurtunity to customers would be probably the best way so that they can do exactly what they want.
But I immediately see this being not so good for those copy/paste-like ones, as it could also be a confusing thing.
Specifically, they would be pasting a text, seeing that fakely wrapped in the RTD textarea (item box), and then see another option to control the number of cchars per line.
I'm just afraid that would be good for a small portion of "geek users", but essentialy unuseful for vast majority of average ones.
At the end, users can ALREADY force the break where they want: they just have to hit "enter" and create a true newline. But the fact they CAN seems not to mean they DO

For our test, as this is going to affect the whole RTD: I made some test and so I pick the extreme but safest value of 120.
I ahve already implemented that, and this of course will change also how you control different values for different products/sizes. For this, I'm now going to update the first post of this announcement with the new instructions, to avoid confusion for who might be reading this later on. So, please refer to updates in there.

Well, we will hope our customers can cope with this problem when the time comes.

We also would really love to see bold/italic text as toggles. Other programs do similar tasks, such as:

http://www.diyawards.com (has bold/italic)

and

http://www.award.com (font sizes, text wrapping, bold, italic, etc.)

I don't know what system they use, but they do all the things we want for our customers.

diyawards seems to be using flash, so can't test it in full (I disabled flash ages ago because of its security issues). This means that it would not work on mobile devices which does not support flash as well, btw.

award.com is nicer for sure. But there you see the main "issue" of tools like the RTD.
That designer is built specifically around that one kind of product. This means that every tool is designed and placed to be best effective for the scope.
The RTD, on the other hand, is designed since the beginning with no specific product in mind. This means the RTD allows a far greater flexibility, but when compared to a tool designed EXCLUSIVELY for a single product type, no surprise the dedicated tool could look more friendly for end users. But this fact of us is also the reason why you can have a design tool without facing the high costs of a custom developed tool for yourself only.
Doing what you're asking would be easy if the RTD would be used only by you, but the problem is it isn't: so we have to work around what it offers, eventaully building new tools that will STILL be generic enough for a generic tool as the RTD is.

This is actually what happened with the new tool created during this discussion: the RTD is an open project, and always open in being enhanced thanks to user feedbacks/needs.
But when proposing, also the necessity of not disrupting other user's service is required, and this means to always look at all possible scenarios instead of own needs only (that's actually the main part of my job when I have to evaluate if and how to add new stuffs).

That said, the RTD allows you to upload your fonts, and bold/italic are just actually separate TTF files themselves.
Main difference here is you do not have a bold/italic button in the RTD (this because not every font has such variations), but you can see them all when you open the font list.
For this reason a lot of our users made proper use of groups and subgourps for fonts, to create a more natural font selection flow based on the ones they really have/need. For you that would just be the same.

This was to explain the reasons behind my answers. The short version is this:
As things are now we cannot have a bod/italic toggle because it's not given that every font has them, so cannot be set as a default behavior for all RTD users.

Thanks for clarifying.