I'm developing a BlackBerry 10 mobile application using the Momentics IDE (native SDK).
I have a Label which has fixed width. If a Text does not fit in this Label, I want it to be ellipsis (elliding the text with the conventional "..." at the end) in place of a fade effect (just sort of "ghosts" into oblivion) like the Cascades designers have chosen to be in such case like presented in the image below.
Can any one help me on this ?
Since Peter doesn't seem to know how to do this in a straight forward way, the only option left would seem to be the complicated way. You may, of course, create your own control and manage the text rendering in the way you would like using an ellipsis instead of the fade. That would seem to be a great deal of work for what in the end will really only result in your program being unconventional on the platform.
Edit:
Since you think it is worth a bounty I will add the following thought.
Using the ellipsis method, instead of the fade method, may impose a performance penalty on your application. Elliding text requires the computation of how many characters may be displayed int the available area and still leave room for the ellipsis. This is not a trivial mater with variable width type faces or different character sets. The fade, on the other hand, is a simple transparency operation. Since UI graphics operations in Cascades are all done in hardware the fade is quite efficient and independent of the size of the string, text area, type face, etc.
Which version of QML? QML element Text has elide property and this is what you want.
Related
Turns out I’m working with the Autodesk Forge viewer and Three.js, trying to render 2D text that can be interacted with (specifically select, rotate, and move).
To do this I am working with meshes (using MeshBasicMaterial, Mesh and TextGeometry) but it turns out that the text does not look perfectly sharp, it presents aliasing and I found that according to the API reference, the antialiasing is not applicable to 2d.
Here are some examples of the problem, as you can see, the more I move away from the plane, the worse the text looks (and even up close it doesn't look perfect):
I have tried to make a test representing the text with a Sprite (despite the fact that it would mean having to change the entire implementation already made with meshes of other functionalities) but apart from the fact that I cannot see it, I have seen example images and they do not appear either well: aliasing is visible from a distance and it looks really blurry up close. Here some examples:
Is there a way to correct this problem or is this the most I can get in 2D? I've tried searching for information on this but can't find anything helpful. And what has puzzled me the most has been realizing that antialiasing was not applicable in the case of 2d, like making it clear that nothing can be done to fix it.
I would be very grateful if you could solve my doubts, thank you very much in advance for your help.
An easier alternative, is to just use a higher pixel ratio for the renderer...
window.devicePixelRatio=2;
viewer.resize();
For example, using the custom geometry text, from Joao's demo, you can see the same aliasing issue at DPR=0.5 and DPR=1.0 ...
https://joaomartins-forge.github.io/textgeometry-sample/
But when I set the DPR=2.0, the text looks clean. The trade off is rendering performance, but your 2D drawings may be simple enough that it won't matter. You can use a 'mouse up' camera settle trick, to switch between DPR of 1 and 2, if you want a better UX experience.
There are a few ways to solve this aliasing issue for 2D (and 3D text).
The way I would recommend for your use case, is to use DIV elements (THREE.CSS3DRenderer), instead of text converted into three.js tessellated triangle geometry, as shown in this blog post:
https://forge.autodesk.com/blog/how-do-you-add-labels-forge-viewer
You can find out more information about THREE.CSS3DRenderer here:
https://threejs.org/docs/#examples/en/renderers/CSS3DRenderer
and an Example here: https://threejs.org/examples/#css3d_periodictable
Using CSS3DRenderer instead of CSS2DRenderer, means you will get the correct scaling (and rotation) of the div element as you zoom into your 2D drawing and the mathematics inside the calculation for the matrix transform has less edge-cases.
Once you are using DIV elements for your text, you will notice that the text is sharper and has no aliasing issues. That's because it is not being rasterized by the webGL pipeline, but by the SKIA library used by chrome/firefox/opera/etc for rasterizing text.
There is one final option, that uses signed-distance fields, but it's probably overkill for what you need.
Let me know if you want some example code.
Is it possible to animate text/object with 'end' in after effects just like you do with strokes? How can I achieve this? See the video and you'll understand what I wan't to achieve.
YouTube - Guy showing the 'end' on a stroke
Cheers,
Tommie
I think I see what you are asking. You want the shapes of a text layer (the actual lines of each character) to actually build on, right? Can't be done like that. Even if you use text and convert to shapes, you are looking at a world of pain because of the way letters are built by most fonts (for one thing, the shapes are actually filled, not stroked -- strokes are outlines).
The only way I would do this is by using the Element 3D plugin in After Effects and Cheetah3D (or whatever 3D tool you want to use). In Cheetah, I'd create the text shapes as extruded 3D text. Then I'd use the "Build" modifier ("Linear" setting) to progressively build the text. Then I'd export that out as an OBJ sequence (script for this is available on cheetah forum site -- I wrote it) and bring that sequence into Element3D and work with it that way. That will work. And as far as I know, that's the only way with a decent amount of control. Wedding video? Just curious. :-)
What kinds of options do I have when a dropdown menu is faced with text that is so wide that extending the menu's width to accommodate is not feasible? i.e. It breaks the page layout, or just looks too ugly if the dropdown is adjusted to fit the long item.
Truncation?
Truncation plus full hover text?
Don't allow items that long?
Anyone encountered any elegant solutions to this?
Thanks.
I realise I'm fairly late to this question, but I've been hunting for an answer and I may have found a fairly elegant solution.
Have a look here:
http://www.getharvest.com/blog/2009/12/dropdown-problems-on-internet-explorer/
http://www.dougboude.com/blog/1/2008/05/Viewing-Option-Text-in-IE7-thats-Wider-than-the-Select-List.cfm
The first link talks about a couple of solutions before recommending a solution based on the second link.
The idea is that on click, you change the width of the <select> tag such that it is big enough to show the full text of the options. By keeping the <select> tag inside a div with overflow set to 'hidden', it doesn't screw with the rest of the page.
Try it out - it's a pretty good solution.
Truncation with tooltip would be my choice....
The last time i had to do that i used a telerik control, which was quite UI rich.
I agree with GordonB regarding truncating the options. Excessively long options can be hard to read, and as you mentioned it looks horrible.
If your dropdown is populated from user input, however, I'd restrict the length. What can be said with 15 words should be said with 5 ... if it can't, then perhaps a dropdown isn't your best option.
For example, if your options are the titles of research papers and their authors, you can probably abbreviate them down to a few key words ("String Theory and You [Brown 2008]"). On the other hand, if the options themselves differ by only a few words and lose meaning if they are truncated (e.g. a list of options like "Peanut butter and grape jelly sandwich with carrot sticks and soy milk" and "Peanut butter and boysenberry jelly sandwith with carrot sticks and 2% milk") maybe you would be better served by displaying all the options sequentially, accompanied by a checkbox or radio button as appropriate.
(If you're using ASP.NET, basically I'm saying using a repeater instead of a DropDownList)
This second approach might also allow you to incorporate other elements that you wouldn't be able to in a dropdown. Take a look at this Amazon search result page for ideas.
Give the element a maximum width with the CSS property max-width.
Most browsers show the options at full width regardless of the dropdown's actual width whereas IE crops them to the width of the select box. So the problem is really browser specific.
I've made a solution using absolute positioning on the dropdown so that I could extend it's width on hover in IE without breaking my layout. A bit hacky but it's one option.
I've been using commercial ASP.NET control that is implemented using <div> rather than <select>. This way we could put multiline elements on it, style it as we wanted and do some other stuff.
Depends how wide you are talking, what the context is. Often this comes down to a design problem rather than a coding problem. If the text is really long you will have usability problems regardless because reading long text in a dropdown is difficult. My options would be:
If the dropdown is really narrow and the longest items aren't very long (eg 3-4 words) change the design to accommodate it.
If the text is really long (eg sentences) then truncate it if you can. Sometimes text isn't amenable to this (eg. you may end up with multiple items with the same text). You can't really put tooltips on select list items.
If the text is really long and can't be truncated, you may want to consider a different UI option.
Why not create a calculated field which is based on the lengthy field.
Only create it to only be the first 50 (say) characters.
=LEFT([Title],50)
Then reference that field in the drop down.
What are the differences between how CSS and Latex organize boxes? (Either paragraph or graphical elements.)
The general scheme, of having a hierarchical boxed representation of page layout produced from processing of input language, and that is then turned into the rendered page, is basically similar between the two models. The four differences that are most impressed on me are:
The CSS boxes model is a robust abstraction, whilst the layout of boxes in the Tex model is operationally determined: as boxes are being laid out in the Tex model, the code can break apart and re-layout earlier boxes.
While Tex's layout model is text-oriented, like the CSS boxes model —and as opposed, to, say Adobe's InDesign page-oriented layout model that's very much about fitting together blocks to cover each page— it still has quite a few page-oriented abstractions, like determining "badness" of vertical space in order to place footnotes - there's nothing like that in the CSS boxes model that I can see. Context has a more sophisticated page layout model, that allows both text-oriented and grid-oriented layout together.
Both the CSS model and the Tex model have notions of block-level boxes (vboxes) and inline boxes (hboxes). However, while you can specify using CSS that a block-level box occurs inside an inline box, section 9.2.1 of the CSS2 standard says that the semantics of this is to turn the outer inline box into a block-level box, so the CSS box model basically forbid block-level boxes from occurring within inline boxes. Tex, by contrast, is happy to have vboxes inside hboxes, which offers power to do things like place pieces of text above text inside a paragraph's text.
Most importantly, the CSS box model has no notion of flexible glue, making scaleable page layout much trickier, and is, I guess, the reason why fixed-width webpage design is dominant.
The specs for CSS are not hard to find and of course they contain a chapter on the box model.
The information is somewhat harder to find for LaTeX, but you can look here, where you can read:
LaTeX builds up its pages by pushing around boxes. At first, each letter is a little box, which is then glued to other letters to form words. These are again glued to other words, but with special glue, which is elastic so that a series of words can be squeezed or stretched as to exactly fill a line on the page.
I admit, this is a very simplistic version of what really happens, but the point is that TeX operates on glue and boxes. Letters are not the only things that can be boxes. You can put virtually everything into a box, including other boxes. Each box will then be handled by LaTeX as if it were a single letter.
I think this is very different from CSS, but for details I'm afraid you have to read books, e.g. The TeX book by Knuth, or the LaTeX companion by Mittelbach et. al.
Miel.
There is a dearth of discussion on this important matter.
There is one key reason I wish that HTML/CSS layout was based on TeX: the lack of glue or springs.
TeX didn't really need to use this feature as the use of TeX was always to lay out content on fixed pages. But the most natural thing on a web browser (ever since screen sizes have gone beyond 640 x 480 pixels) is to resize it, especially the width.
It is impressively difficult in CSS to lay out something like a slide-show, with a frame in the center occupying most of the space and 2 thin stripes of forward and backward buttons, right and left respectively, that then resizes gracefully, especially as we get to the narrow end of the spectrum. But also, on the wide end without wasting all the space in margin as many modern CSS layouts do.
In TeX that is easy. You have an hbox, with a grow- and shrink-able center frame, and the forward and backward button are fixed size.
As you increase the page width, only the center frame expands, and as you reduce the width, only the center frame becomes narrower, until all its shrink value is used up (minimal width) then it stops (and supposedly a horizontal scrollbar would appear.
This is the one key aspect I feel is badly missing from CSS. It is so much more natural, and amazing that Knuth had invented it at a time when dynamic screen layout was decades away from becoming reality. And it is sad that this genius was forgotten.
I assume that the box and glue model was argued to be
too hard on real-time computation capacity of earlier web clients
too "difficult" to implement for Microsoft programmers
too "confusing" for beginners to use.
All of this are very weak arguments IMO.
The same issue appears in Java/Swing Layout schemes. I remember I implemented a real Box and Glue Layout in Java to use with SWT on a project some 15 years ago. Once you have it is's so awesome.
I am awaiting a real box and glue layout option to appear in some next generation of CSS before the end of my programmer career, and I hope soon, so I can still use it for a few years.
I'd love to know how long a string is when it appears on the screen. We're not using a fixed width font, so:
"Our mother's tummy makes dummy noises."
is much wider than:
"Lilly Leadbetter lives life leisurely."
Is there a way to tell how long something is by the characters? I don't need pixel perfect accuracy, just long enough to ellipse at roughly the right spot. CSS overflow won't help, because I can't attach the ellipse after CSS has determined how long it is.
Here's a related question with at least a partial solution. Basically the technique is to render the text in a hidden <span> and then (using JavaScript) measure the pixel width of the span, then chop off characters until it fits in your target width.
And here's a jQuery plugin that encapsulates this sort of functionality, linked from this related question.
Ordinarily I'd agree with fsb that you have to understand that on the web you don't have pixel-perfect control over everything. It's not print. Choose a reasonable length and chop it off server-side, you can avoid chopping in the middle of a word to make it look a little better.
If you insist on a perfect length though, check out ThreeDots, a jQuery plugin.
Unless you're using a fixed width font, I don't think there's any simple way to tell. Perhaps the easiest way is to render the candidate text and see how long it is.
Server-side, this is a bit hit-and-miss because you don't know for sure what the browser is going to do with the text. You could use GD (or something like that) and your best guess what font and size the browser will use but is it worth the trouble when you can't trust your guesses?
Client side in javascript (or whatever) you can have the browser render the text and look to see how long the rendered DOM object is (as Jordan said).
One solution, though perhaps very hard psychologically, is to understand that web page rendering is not typography. You do not have control. You do your best, accept the limitations and move on to the next problem. Technically simple but maybe hard to accept.
You can use the truncate helper function. Even if you know about the visual length, you cannot probably optimize it for all browsers/browser window resizes.