In actionscript 3, my TextField has :
CSS styling
embedded fonts
textAlign : CENTER
autoSize : CENTER
... when italics are used the very right character gets slightly cut off (specially caps).
It basically seems that it fails detecting the right size.
I've had this problem before but just wondered is there a nice workaround (instead of checking textWidth or offsetting text etc.)?
Initialize your textField as you always do, using multiline, autosize, htmlText...
Then do this little trick :
// saving wanted width and height plus 1px to get some space for last char
var savedWidth = myTextField.width + 1;
var savedHeight = myTextField.height + 1;
// removing autoSize, wich is the origin of the problem i think
myTextField.autoSize = "none";
// now manually autoSizing the textField with saved values
myTextField.width = savedWidth;
myTextField.height = savedHeight;
Not that it is much comfort to you, but Flash sometimes has trouble with this seemingly simple task. CSS styling of html TextField was a nice addition but it has caused headaches for text-rendering. In fact I very rarely use CSS for styling text for that reason. I can only imagine that combining bold, italic and normal type faces within the HTML causes Flash to get some of the width calculations wrong which causes autoSize to set the mask a tiny bit short. I hope very much that the new text rendering engine in Flash Player 10 will finally fix these issues (it certainly looks better in theory).
So my solution is never to use HTML with the exception being when I require <a> links in my text ... and there are even some tricky text shifting issues there. In those cases I avoid mixing different font weights and font styles within the same text field. All other cases I use TextFormat directly on TextField.
I suppose if you can't get out of your current architecture (for some reason) you could try adding to the end of your html encoded strings. Or you could manually set the width of the field and not rely on autoSize (as you have mentioned). But if you keep on the CSS/HTML route you may find another new and painful limitation just when you don't want it.
I've had issues with TextField masks behaving differently in the Flash preview, and in the actual browser plugin. Usually, and this is strange to me, it would appear more correctly in the browser. Have you tried running the swf in a browser to see if the problem is actually an annoyance rather than a permanent problem?
I had said this:
My in-ideal approach to solving this is to attach a change event to the TextField which always adds a space after the last character of the field. And then to remember to trim this space off when using the value.
But that didn't take into account that this probably doesn't have a change event and that it's an HTML rendered text field. To add a trailing space in the HTML text field throw in an again, that's not really fixing the problem.
Related
I have a bitmap font built with Hiero, which I'm using in scene2d Labels.
In a single Label instance I need to reduce the font's lineHeight value, but I'd like to leave the other Labels (which are using the same font) intact, so they should keep the default lineHeight of the font.
I've tried to simply adjust the value like this:
label.getStyle().font.getData().setLineHeight(localReducedValue);
However, this has modified all the Labels everywhere -- which, in retrospect, seems logical, since I'm modifying the LabelStyle itself.
Unfortunately something like label.setLineHeight(localReducedValue) doesn't exist, so at this point I see two possible solutions:
Create a copy of the font, set its lineHeight to the value I need, and create a separate LabelStyle with that font; or
Write a custom Label for myself which implements setLineHeight.
The first idea seems wasteful, the second is likely a bit complicated, so I'm hoping there's an easier way of achieving a temporary lineHeight in Labels.
Nathan Sweet, one of LibGDX's core developers has kindly suggested a solution, which is working perfectly:
Override Label#layout, set line height, call super.layout, set line height back. You need to use layout and not draw because layout computes and caches the glyph positions, draw just draws them.
You can change the LabelStyle of a single Label by doing something like this:
//skin is the skin that you use
Label myLabel = new Label(text, new LabelStyle(skin.get(LabelStyle.class)));
And then you can modify the style without affecting all the labels.
I am sure you guys must have seen that font resizing option on some website where they display alphabet "A" in small, medium and large sizes clicking on which changes the font size of website. I have two questions:
What is that thing called actually? Like if there is a term to describe it?
What arguments can I give against using this on website? One of the client has asked to incorporate it in website and I don't see any real benefit in using it so what arguments can I give to client against using it?
It is called "font size change options", or "font resizer".
Here is a simple and minimal 5 lines of code jQuery tutorial: http://www.programming-free.com/2013/12/increase-decrease-font-size-jquery.html
A bit of the code that enlarges the font size:
newFontSize= parseInt($('#content').css('font-size')) + 2;
$('#content').css('font-size', newFontSize);
The user could just use CTRL+ in browser. The problem is that the final user doesn't know this trick.
This is a fast and simple implementation, no need to convince the client against it. I find myself getting hard to see clear small text after 10 hours of programming. Maybe the client has sight problems and needs to address others like him.
"As of jQuery 1.6, .css() accepts relative values similar to .animate(). Relative values are a string starting with += or -= to increment or decrement the current value. For example, if an element's padding-left was 10px, .css( "padding-left", "+=15" ) would result in a total padding-left of 25px."
Reference
So to do that you can use a function callback which will return the actual value, then you return the new value.
Like the following.
$("#fontPlusBtn").click(function (){
$("#textDiv > *").css("font-size", function(i, value) {
return parseInt(value) * 1.1;
});
});
Working Demo for Increasing Font Size on Button Click:
I hope this helps you as you described font size change on Button Click.
What is the target group of your client? Adding such feature is generally considered good practice of web accessibility. It doesn't really take up too much space on the screen and doesn't mess with the design but gives users the options to enlarge the text in case they are having troubles reading the text.
I wouldn't try to argue against it but instead find a neat way to implement the functionality.
BBC's accessibility policy is a good read: http://www.bbc.co.uk/accessibility/best_practice/policy.shtml
I need to determine minimum width adequate for displaying a possibly wrapped dynamic HTML string. Without word-wrapping this is simple: create a span, set its innerHTML and read offsetWidth. However, I'm not sure how to force linebreaks... Easiest incomplete approach I see is to replace all spaces by <br/>, but lines can be wrapped not only on spaces but also e.g. on hyphens.
So, basically, I want a browser to lay out sth. like
Max.
word-
wrapped
string
<----->
somewhere off-screen to measure width of the longest contained word. Is there a generic way to do that?
EDIT
I.e., for no line wraps:
function computeWidth (str) { // code to make it off-screen and caching omitted
var span = document.createElement ('span');
document.body.appendChild (span);
span.innerHTML = str;
return span.offsetWidth;
}
How would I write a similar function which forces line breaks on str, presumably playing with span.style?
You can use CSS work-break / word-wrap and programmatically inserted soft-hyphens (, but I'd advise you to read up on cross browser problems regarding soft hyphens, as there are quite a few - I normally us the unicode for a soft hypen (U+00AD), but your mileage may vary), and then determine the width with javascript using the range object and measuring cursor offset from the left.
I'm suggesting the use of soft-hyphens, because even the same browser will normally break words differently depending on the OS / which dictionary (on OSX) is used. If that's not an issue for you, you can do it without soft hyphens.
Afaik there is no generic way to get what you want in html/js (it's different if you were using something like flash).
Range object:
https://developer.mozilla.org/en-US/docs/Web/API/range
A different approach would be using the canvas object, but you would probably not get exact results there, as there is just too much factors influencing text rendering in browsers nowadays (font, size, kerning, tracking, ...)
Again another approach would be using <pre> tags / whitespace: pre-wrap, setting the font to what you normally use, and then either emulate breaking words by inserting linebreaks or copying them from still another span/div/whatever set up with word wrap - I haven't tested this yet, but if it works, it might be easer than iterating with the range object.
Edit: Just so it's not only in the comments, still another solution:
Start your container with width 1px, then increase the width, checking the height every time ; when the height decreases, go back one step, and you got your width. Simplest implementation would use 1px increase/1px decrease, but you could of course optimize it to using something like a binary search algorithm, e.g. starting with 1px, then 2px, then 4px increases, then the same backwards, and forwards again and so on till you have a result at a 1px step. But that's only if the 1px inc/dec sollution is too slow ;)
Use the CSS word-break rule:
The word-break CSS property is used to specify how (or if) to break lines within words.
Normal
Use the default line break rule.
break-all
Word breaks may be inserted between any character for non-CJK (Chinese/Japanese/Korean) text.
keep-all
Don't allow word breaks for CJK text. Non-CJK text behavior is same as normal.
<p style="word-break:break-all;">
Max.word-wrapped string<----->
</p>
(source)
Try to play with the word-break Property.
More here: http://www.w3schools.com/cssref/tryit.asp?filename=trycss3_word-break
You should try:
word-break: break-all;
Add it to the CSS like in this fiddle, or read here.
Alright, So I have an issue that is a bit weird. I am using a RichTextEditor and have allowed the user to re-size it. All the controls have been stripped away to a main toolbar such that the RichTextEditor just looks like a box with text in it. I have an issue where when I save the htmltext generated by the editor and then re-render it later it always adds an extra line break at the end of the text. I've found that this is due to the paragraph tag, and since I want the user to be able to align text I have to keep it. Does anyone know how to strip this last line break without stripping all the formatting?
I hacked a fix for this, basically involves stripping the last closing paragraph tag </P>. RichTextEditor is ugly :(
This is absolutely a bug, and it is triggered by setting the "htmlText" property instead of the "text" property. This occurs whether you assign it in code, or cause the designer to set "htmlText" instead of "text" by checking the "render as html" button in the properties for the text field. Also of note, this only occurs on "input" type TextFields. And if you start with a "dynamic" type textfield and subsequently set "type" to "input" (also have to set "selectable" to true or cursor will be invisible (another bug)), you will see the extra line appear right in front of your eyes. Again, this does not effect dynamic text fields, just those in input mode.
Despite the fact that the htmlText property is identical in both cases whether you assign a string like "Hello" to text or htmlText (the htmlText value generated is identical for either), the extra line only appears when setting the htmlText property.
Specifically, it occurs when you set htmlText to a string that actually contains html paragraph tags. If you just assign htmlText some text like "Hello", the problem will not occur. On the other hand, if you assigned htmlText <p>Hello</p> or you assigned htmlText to itself (which you need to do to preserve the html and force the internal metrics to update immediately), then the problem occurs. Someone mentioned, if you omit the closing </p> tag, the problem won't occur, and that's true. It's also true that assigning something like <a>Hello</a> won't trigger the problem.
So in summary, this problem occurs only when one sets the htmlText property of an auto-sized, multiline, input type text field to a value that contains <p></p> tags. It does not occur with dynamic text fields, nor does it occur on input text fields that are not autosized, nor does it occur on those who are autosized but not assigned <p> tags to htmlText.
To reproduce this problem, set up a text field in the designer and make sure the background and outline is turned on so you can see the size of the field, then it will be a single line high (multiline text field) as expected (assuming it's wide enough). If you then go to the code and set txtfld.htmlText = txtfld.htmlText (set it to itself), this mere assignment of htmlText property (to it's own same value) causes an additional line to be added. And the value of htmlText is in fact the same, it hasn't actually snuck in an extra <p> tag or anything... it just displays this trailing return that shouldn't be there. As expected, the same thing occurs when you check "render as html" in Flash properties for the text field, which seems to cause it to set htmlText instead of text, and causes the problem to appear.
It's unlikely that there are actually two rendering modes, since it technically always renders htmlText (i.e. htmlText always has a value, and you could always set the text format of some segment of the text with setTextFormat, which was originally assigned with "text", and that doesn't trigger some kind of switch to "html rendering mode" or anything like that.
The behavior seems to strictly come as a result of assigning htmlText property.
The only way to avoid it (aside from setting htmlText, reading back the value, stripping the last </p> tag off, and reassigning it), is to just initialize all your text fields as plain "text", and then manually apply the formatting through calls to setTextFormat( TextFormat, beginIndex, endIndex).
The true catastophe of this bug, as mentioned in the original problem post, is that you cannot save and restore the htmlText value of a TextField, because setting htmlText to a string containing html (specifically the p tag), causes this extra line to be added, compounded by the fact that if you specifically want the textfield to be sized right, you'll probably have autosize turned on, and that's specifically when this problem creeps up and ensures the size is NOT right.
I had a similar headache with flex html text components. Flex does not have proper support for many html cases. You'll see extra padding for <p> and <li> all the time. Heck, there isn't even support for the <ul> tag. If there is a line break in a normal text, flex appends extra padding at the end of the tags and removing this line break will remove the extra padding.
However, you might want to use something like this: http://code.google.com/p/flex-htmlfilter/
in AS3, I'm making this dynamic textfield that is populated from an XML file based on where the user clicks.
The dynamic textfield has a custom scrollbar to it. My problem is that if the text inserted into the textfield is less than the previously displayed text, you can still scroll the dynamic textfield as far as the previous one.
Is there a way to reset the textfield autoSize?
Many thanks,
If you are talking about Flash ( I have very little experience in Flex ) then the textField.autosize property would probably get you in the right direction.
I think this link will tell you exactly what to do.
Are you using any of the standard flex controls? Or, is this flash?
You can set the width of the field to the string length + some space (by binding the width to the string's length/event handling etc). This may be of interest. Of course,
Try this, wrap the xml elements text in
<text><![CDATA[<span class="someClass">Some Text Here</span>]]></text>
If the prior wasn't wrapped in CDATA, flash would have taken the <span class="someClass"> and attempted to drop it down a line and indent it as you would with XML hierarchy; CDATA tells flash to ignore those characters and literally treat them as a string. The result of not using this process is that there are many odd spacings in your textfield.
Also be sure that your TextField is set to Multiline and wordwrap, as well as autoSize such as TextFieldAutoSize.LEFT;