RealTimeDesigner Support Network
Wiki Forums Libraries Docs Support RealTimeDesigner Home
Welcome! Log In Create A New Profile

Advanced

text handling

Posted by candycartons 
text handling
December 17, 2015 10:51PM
I understand that once a text element is re-sized that the bound box is then "set." So, when that text is subsequently edited, it will squish if one of the lines is too long (longer than the longest line in the original text), or stretch if one of the lines is shorter than the longest line in the original text, all in order to mash the text into the set bonding box.

My templates have lots of multiline text, and this is resulting in a lot of difficulty achieving a good looking result particularly because I need to have placeholders with sample text in them for my customers to edit.

For example, I will have the following default text element on my template (center justified):

First Lastname
(555) 444-3333 mobile
(555) 444-2222 office
youremail@address.com
www.yourwebsitehere.com

Now, if a customer edits the text it will squish or stretch the text to fit within the "set" bound box.

Here is my question: Can a <script> be used in the product footer that would prevent the text bounding box from being "set" upon resizing, or ever? I find that the behavior of the text element is much more intuitive prior to the bounding box being "set", where the bounding box will actually expand or contract to meet the text boundaries, rather than skewing the text to meet a predefined area.

I hope this is achievable. In my humble opinion as a graphic designer, text should never be squished or stretched unless the user specifically wants to achieve that effect. If a customer types in too much text on one line of a multiline text area (a long website address for example) then they would naturally grab a corner and drag the entire box smaller and maintain proportion.

So basically, can I have the bounding box resize iteself to the longest line rather than have the text distort itself to fit within the original bounding box?

I have tried many different attempts and solutions using the "Proportional Text / Fixed BBox" to no avail. I do not want to have to lock the element in place and disable resizing.

Here is a link to the template I am trying to perfect:
http://designer.realtimedesigner.com/designmycandybox/index.php&tng=Y3BpPTc2NDc1JmN0aT0yNzE0Mw==

Notice how on "side 4" the bounding box will expand or contract to meet the longest line of text. This is the behavior I desire (as opposed to "side 2" where the bounding box has been set). The problem is that I am forced to used the default text size set in the product defaults. If I resize the text using the corner handles then the bound box will set.

Thank you for all you do. I look forward to hearing back =).

Greg Beckemeier
The Candy Box Guy
(636) 542-8560



Edited 4 time(s). Last edit at 12/17/2015 11:00PM by candycartons.
Re: text handling
December 18, 2015 08:45AM
Update: Here is a link to another vendor I was considering before making the commitment to RTD. Notice how the text fields are handled. This is exactly what I need. I am willing to pay for it:

http://candybox.udraw.net/product/sold-picket-fence/

Notice how the bounding box expands and text is never stretched? Also important, notice how the text is center justified and the bounding box expands from the center out, meaning the customer will not have to reposition the element after editing the text, making for a more pleasurable experience.

I would like to get a quote on how much it would cost to implement the exact same type of text handling, if possible?

Also, I would also like to get a quote on the possibility of having customer-replaced-images appear center justified within the original bounding box without stretching, rather than left justified.

Greg Beckemeier
DesignMyCandyBox.com
(636) 542-8560
Re: text handling
December 18, 2015 01:24PM
Greg,

so much to say, but first need to think at the appropriate answer.
I'm replying now just to notify you I saw this and I will reply better in the next days.

Thanks!
Re: text handling
December 18, 2015 04:11PM
Alex, please don't feel like I need a long explanation. I know your time is more valuable than spending it describing why or why not something can be implemented. A yes or no will be fine with me. If the answer is no, I trust that there is a very good reason why. I feel bad enough already with all these posts =(.

Greg
Re: text handling
December 18, 2015 06:14PM
This response and three others like it solidify my concern over how text is handled:

++++++++++++++++
Michelle Sealy <michelle........om>
4:57 PM (14 minutes ago)

to me
Greg,

I'm coming from a graphics background in Freehand, Illustrator, Indesign, Photoshop. So, my input may be a little different from other realtors who have no experience with graphics.

The original layout:
It works well because there isn't any guess work as to where information should be put. The margins are already predetermined and each element is already centered. The less we have to think about something or learn something new, the better.
Most realtors may want new pictures or may change brokerages or have different email addresses when it comes time to re-order. The amount of information that has to be entered into this layout is really minimal. I believe having to repeat this process every time an order is made is not going to be a big deal. Especially when half the information may need to be changed for the above reasons.

IF you have clients who are sure that they will not be changing any information and just want to re-order boxes, perhaps you could keep a pdf of the file on a cloud service. Dropbox, Evernote, ICloud, etc. Label the pdf with realtors name and retrieve that file on the reorder. Or, send each client a pdf of their layout and have them send it back to you for each re-order (this option, you do not have to keep track of layouts)


The new saved layout option.

Concern that there aren't any margin guides to indicate a good suggested area to keep text and photos in. This information may wind up too close to the folds and you may have unhappy customers because the final product is not what they thought they were getting.

For the creative ones, the new saved option may be nice. I played around a little bit with it. I became a little frustrated by the way the text boxes were responding.


I guess it boils down to:
1. Are you getting a lot of grief for having to enter all the information on every order?
2. If you are getting grief, is it just a few or is it enough to hurt your business if they went elsewhere?
3. Which works better for you?
4. Which program helps you to streamline your business?
5. Is there a cost difference?
6. If the current process works well for you now and it insures you have consistent results without worry of mistakes/headaches, it may be better to keep things the same.

Just my thoughts. I like the original layout better.

Michelle
+++++++++++++
Re: text handling
December 19, 2015 05:49AM
Greg,

There's never a solid "no".
But a "long explanation" might be needed as well, because you're still pretty new to some concepts of the RTD in general.
If we never faced the kind of issues you're having, it's simply because so far it was not strictly needed.
Also, spending time in making a "long explanation" often gives hints about where the solution might be. So I'm both explaining to you AND to me smiling smiley

Technically what you're asking for is surely doable, but it might take some time because it needs to be integrated in the current RTD system without affecting anything that's already in place.
That's basically what we do in the forums: you express what you think should be changed/added, I find the eventual issues related to legacy, and we brainstorm togethere to find the best possible solution.

That said, what makes you unique here is the need for texts you have: several RTD users really needs very simple texts which are very rarely that different from what's defined in a template. You scenario is extremely valuable to make the end-user experience even better.

I think there's room to even change some of the fundamentals of the RTD, but for this I need to first explain why some tools are working as they are.
1st of all: why something like forcing elements (texts and cliparts) to fill the defined box instead of keeping proportional?
Simply because of the possible scenarios. Easiest one is about BG images: in that case you really want the space to be completely filled. Another one are distorted texts: often, for a good final view, non-proportial scale might be needed in order to achieve the desired effect.

For this we added the tools to foce proportional items, but only at template level. And thats probably where we have to start our research.

1st think at the forced proportial for cliparts, which you are probably using for your photo placeholders. you'd like it to be centered, and I 101% agree this needs to be solved in some way.
Issue to face: we really know how big the new image is only once it's loaded. So, need to find a way to temporary store the original coords of the placeholder first, then apply some replacement math once the new image is fully loaded (and checkable). this would be it from a logic standpoint. And of course, this should happen only and exclusively when the clipart has the "force proportional" active.
The good news: yes, that's something a well written script can do!

Next about texts.
A scenario like yours would work only when no distortions could ever be involved, which is actually your case.
When a bbox is set, the RTD assumes that's what the user wants, because someone sized the box to that size.
Reason why, without a box defined, the define fontsize of the product is used is simply because at first the RTD has no references to calculate any bbox. And so in that case, it creates the bbox around the fontsize (that's why in that case the box expands/contracts).
When a box is defined, the RTD is really doing the same thing: but at the end of the process, it resizes the text image to match the boxsize.
But in the other website you linked, behavior is even different: the box expands/contracts, but it also allow you to stretch/squeeze. So, basically it's not a proportional text at all.
If I have to think at all of this, it looks like you might be in need of redefining the default text size in some different way.
The good news here is I can surely think at something to allow a different control over the text size. However, a control like that would work only for proportional text.

I am just thinking out loud here. Do not read any of this a strong promise yet. Actually, I am making some tests already.
I guess you might get a call for a test session at anytime!

Now back to testing.
Re: text handling
December 21, 2015 03:37AM
Alright, I do have a concept test.
But first, I have to spend few words on the technical "why".

As you know, the initial text expands because there'no bbox defined. In that case, we use the default textsize defined per the product.
Then, if the resulting text image is bigger than the printable area, the text is automatically scaled down to fit the product: but when you resize/stretch/squeeze with the arrows, the bbox is defined.
In that moment the RTD assumes everything you do MUST stay within the defined box, and that's basically what's causing your issues.

The problem, a legacy one actually, is that the RTD is not allowing the user to define a text size: that's what makes impossible to "auto expand", simply because the RTD calculates automatically the size to use by using the text length and the bbox size as parameters.
Given that, the test is about giving the ability to define the text size: that way, the text could expand because the RTD would know which size it should use.

Main drawbacks are only 2:
1) in this way, text can only be proportional: no stretch/squeeze can be allowed
2) the size of the text can no more be defined by dragging arrows, but only by defining the font size.
I know that still having the arrows would had been more desirable, but for how the RTD is built since the very beinning that's not currently something that can be implemented at present stage.

My test is about doing all of this with a new proportional property for templates named "expandable".
It is not in the regular RTD, only in my testserver to try the concept at a technical level.

And now, about the test itself. Here's the link:
http://testserver.realtimedesigner.com/screenprint/index.php&tng=Y3BpPTYxNCZjdGk9OTU=

There are 3 texts in there.
top-left is using the proportial feture with the NONE option
top-right is using the proportial feture with the CENTER option
bottom-middle is using the proportial feture with the experimental EXPANDABLE option

The ones on top are the ones currently avail in the RTD. So the one you should play with is the bottom one.
When selecting it, you will notice there will be no arrows shown, but there will be a slider on bottom of the item box on the right. When you move it to change the size, the text will update accordingly.
But if you will try to change the text length, you will see that the font will stay the exact same: expands if you type more, stays the same if you type less.
That slider can be placed in any other location, it is there just for this test.
But what I need to ask you now is how you feel its behavior.

Let me know!
Re: text handling
December 23, 2015 01:56PM
Hi Alex! Just getting into reading your indepth responses.

You Wrote:
****
Main drawbacks are only 2:
1) in this way, text can only be proportional: no stretch/squeeze can be allowed
2) the size of the text can no more be defined by dragging arrows, but only by defining the font size.
I know that still having the arrows would had been more desirable, but for how the RTD is built since the very beinning that's not currently something that can be implemented at present stage.
****

For my product, this would actually be AWSEOME and not drawbacks. It is the exact way my current vendor operates. A user is basically resizing the text area only, and the text within the text area will reformat itself as you resize the text area. If a user shrinks the text area too small, a warning pops up that notifies the user that all the text cannot be displayed. The only way for my customers to increase or decrease the size of the text is to change the point size. This is the ideal way to handle text for my product, and my customers love it and quickly adapt.

Here is a link to a template from my current vendor Aleyant (not to be confused with uDraw from my previous link sample.) Notice how text is handled. it works very well:
http://www.designmycandybox.com/module/edocbuilder/edoc?http://www.designmycandybox.com/real-estate-agents/123-thought-i-d-pop-by-theme.html

Okay, going to keep reading further into your replies and keep digging =)
Re: text handling
December 23, 2015 01:58PM
Another thought before I keep reading: Perhaps a "Convert to Art/Curves" button for people who need to stretch/resize text using handles. While this would be of little use to my customers, perhaps it would be a better way for others who want both worlds of better text handling AND text resizing/stretching.
Re: text handling
December 23, 2015 02:29PM
Alex, a family emergency has come up again. Sigh...

I will test out your link tonight when I return or tomorrow morning.
Re: text handling
December 24, 2015 12:46AM
Ok. Regarding the "bottom-middle is using the proportial feture with the experimental EXPANDABLE option "
at the following link:
http://testserver.realtimedesigner.com/screenprint/index.php&tng=Y3BpPTYxNCZjdGk9OTU=

*I think the slider bar solution for choosing font point size would work great. But, wondering if a dropdown list for font size would be better? Can't decide.
*most of my fonts will range from 8 points to 16 points. I notice that at these point sizes, the "ALIGN-->DECREASE SPACING" currently decreases the space too much for a single increment. Any way to remedy this?
*When using the slider bar to adjust point size, is it possible to have the bbox expand/contract from center/center rather than left/top?
Re: text handling
December 24, 2015 04:45AM
Greg,

Sorry to hear about emergencies, hope things are getting better now.
As per your questions, I have good news. Please just refer to the same link you tested, something is now different!

1) I made the center-center thing. When using the resize, new text will be repositioned as you asked
2) it is independent from the slider, but right after it I've now added also a dropdown version of the size selector. Now you will need to decide which one works best, actually!
3) the spacing issue: I'll have to debug this a little more. IT seems related to the proportional thing, but still had no tie to properly test in depth.

All for now.
And as it's the 24th, also MERRY CHRISTMAS to you, your family and all of our readers (if any)!
cos
Re: text handling
December 24, 2015 06:09AM
I'm reading. Merry Christmas to everyone.

This has been interesting to follow and will benefit many. I think most users would be familiar with a drop down method for size. I really like the slider better, but only if the text is instantly responsive to the slide like the rotate text works. The pause for text update is cumbersome, even for me.
Re: text handling
December 29, 2015 12:57PM
Merry Christmas to you as well, Alex! And thank you for your input, cos, it helps greatly.

I'll have time today to go back and try the link again. will post soon. =)

Greg
Re: text handling
December 29, 2015 01:05PM
Alex... Bravo! LOVE it. I do like the dropdown better than the slider for choosing font size.

Also love the way the bbox expands from the center out when changing font size.

Question: can the bbox also expand from the center out when a user is typing into the text area? The auto-update still expands the bbox from left-top while typing. Does this make sense?

Greg
Re: text handling
December 31, 2015 03:24AM
It does sense, but that would be much harder.
Fact is we're running "sizeless" now.
This because we're only passing the fontsize parameter to auto expand, which means the interface no longer knows how big the image is, until it is loaded.
And as we don't know the size, making it centered is impossible because we miss there "centered against what?" parameter, in some way.
Only way out would be to temporary store the previous text location, which is what I'm doing for the center-center while resizing. But this would no more be an effective way if applied also to text changes. This could only work when we're forcing a dedicated position to the whole item, which is the behavior of the LEFT, CENTER and RIGHT proportional properties (which are infact locking also the template position).

Perhaps in the next days I'll have a "genius inspiration", but right now cannot really think at an easy way out to obtain this.
Will keep checking on this, though!
Re: text handling
December 02, 2018 07:48PM
I tried your proportionate feature with the experimental EXPANDABLE option for the bottom text on:
http://testserver.realtimedesigner.com/screenprint/index.php&tng=Y3BpPTYxNCZjdGk9OTU=

This does exactly what I want but I cannot see how I can implement it. I want the text size as a drop-down like in your example, and the bbox expandable. How can I do that?
Re: text handling
December 04, 2018 12:36AM
That's experimental and no one ever asked again about it in the latest 2 years. So until now it only resided in the testserver.
However, if you're willing to test it, I now released it in the regular RTD as well.

You can find it as latest radio option in the Proportional Text / Fixed BBox under Show Advanced Admin Options for the item.
Please note that even there I am calling that EXPERIMENTAL, because that's what it is. Feel free to use it and report about issues with it, but carefully remember it had never been tested in production by anyone yet
Re: text handling
December 04, 2018 04:59PM
Thanks, Alex. The only problem I am having is the limited number of selections for Arch degrees. Proportional and Expandable text on an arch requires more fine-tuned degree options. Is it possible to be able to have the degrees in steps of 5 degrees(i.e. 5, 10, 15, 20, 25, etc...)?
Re: text handling
December 05, 2018 03:53AM
Uhm... kinda.
I assume you're talking about radial arch, which currently shows 10 degrees values.
If I change it to be a step-5 list, that would result in a list of 72 elements. With such amount I don't think the dropdown would be effective anymore probably.
Before I do anything, what do you think about that "issue"?
Re: text handling
December 05, 2018 01:03PM
You might be right about such a long list of degrees, I had not thought of that. A slider would probably be better. Is that possible?
Re: text handling
December 05, 2018 01:46PM
Also, I just noticed that the maximum character size (50) is very small if the user only had a few letters/numbers in a line of text (see attached) and it would have the same issue as your concern for the list of degrees for arch radius. Is it possible for both to be a slider and the max character size much larger than 50?
Attachments:
open | download - screenshot-designer.realtimedesigner.com-2018.12.05-09-40-50.jpg (356.6 KB)
cos
Re: text handling
December 05, 2018 03:38PM
I like this direction!
Re: text handling
December 06, 2018 02:34AM
I will have to test a little to make a slider for Arch. In the meanwhile though I added one for char size, which now allows o go up to 120. Can you try thatand let me know how you feel it?
You know, the only "issue" I see with sliders is the response time.
We now have sliders for rotation, but that happens immediately. On the other hand, the char size will take a little time to generate the new image. What I'm trying to avoid is users to keep movine the slider simply because they're not seeing someting happening immediately. This can be easily seen when using longer texts rather than single line ones though.
For this, I'd like you to try how you feel it now but lso keeping in mind the end user experience.

Let me know!
Re: text handling
December 06, 2018 12:29PM
Alex, I LOVE the slider. It does take quite a while to refresh, which would affect user experience; however, without an alternative, it is much better than before. I think it would be more intuitive for the user to wait if the rotating status icon was more obvious. I've seen sites that have the rest of the page grayed-out in the background with the rotating status icon in front until the response is completed. That way the user cannot move the slider again until the process is completed. Is that possible or too difficult?
Re: text handling
December 06, 2018 01:14PM
I'll have to try. I am closing some open projects now, so I'll see if I can test a little during the weekend
Sorry, only registered users may post in this forum.

Click here to login