There is still no lineheight and letterspacing option in display.newText() method, right?
Why is it so? Is it difficult to implement?
I wanted to make a new business app but not having these features will eventually make me jump to another sdk.
best regards,
roamn
At this time we do not support line height or letter spacing. I don’t know how difficult it is to implement, but like any thing, it takes engineering time and we have to balance adding features vs. fixing bugs. We also have to consider all of our customers and do what benefits larger groups of people.
If you have not done so, visit http://feedback.coronalabs.com and see if there is an existing entry for this and vote it up if it’s there. If you can’t find a similar request, please create one and get people to vote it up. We have to show Engineering how important this feature is to the community to get it implemented (assuming it’s not a very difficult task)
Rob
It’s not particularly difficult. In the Corona scheme of things it’s not going to be a top priority I wouldn’t have thought.
My bitmap font library does both (it wouldn’t be any use for a business app though it would work ?). One way round it is to basically ignore newText() except as a source for single character display objects of a particular font and write a library on top that creates a display group full of these characters and manipulates it accordingly. As long as you are not attempting to redo Microsoft Word it would be quick enough and you can add all the functionality you want to taste.Â
At this time we do not support line height or letter spacing. I don’t know how difficult it is to implement, but like any thing, it takes engineering time and we have to balance adding features vs. fixing bugs. We also have to consider all of our customers and do what benefits larger groups of people.
If you have not done so, visit http://feedback.coronalabs.com and see if there is an existing entry for this and vote it up if it’s there. If you can’t find a similar request, please create one and get people to vote it up. We have to show Engineering how important this feature is to the community to get it implemented (assuming it’s not a very difficult task)
Rob
It’s not particularly difficult. In the Corona scheme of things it’s not going to be a top priority I wouldn’t have thought.
My bitmap font library does both (it wouldn’t be any use for a business app though it would work ?). One way round it is to basically ignore newText() except as a source for single character display objects of a particular font and write a library on top that creates a display group full of these characters and manipulates it accordingly. As long as you are not attempting to redo Microsoft Word it would be quick enough and you can add all the functionality you want to taste.Â
I am very interested in this feature too. Same as paulscottrobson, we are using Corona as business app too.
Without this feature, the whole reading experience is not superb.
Strongly need this feature.
Thanks.
You could probably approximate it - for each character create a display object for it , measure its width then delete it (only need to do this once) and then use this to convert your space split string into a string with newlines at the appropriate points.
Well this seems like only way, but for some font like Chinese, breaking it will be a very challenging work, as corona dont treat each chinese character as a string character.
And not sure how is the rendering cost, because I am rendering a whole long list of paragraph that is about few thousand characters.
Lua and Corona probably aren’t ideal for Chinese and similar fonts. I think you end up doing your own encoding a lot of the time - my BitmapFont library has options to change the encoding to UTF-8 so the non ASCII characters can be used but I don’t think it is very well supported. In terms of the rendering cost, Bitmap font libraries will almost all be 1-1 character -> Corona image, so using the stock text is best at that sort of level. I would think the actual rendering would be fairly efficient, because it’s probably just directly calling an Android/iOS function or two which does that. You’d probably just have to experiment with that - if you are thinking of running on a phone hardware scrounge an old discarded Android phone off someone who has upgraded and see how that copes with it. I also tend to have a really cheap (£40 ish) android tablet as well for this sort of testing, stuff can work fine in the simulator but the cheap hardware can’t manage it (though in my experience you have to really flog it !)
Lineheight is currently really bad in newText.  I’m surprised there aren’t more posts about this.
The standard lineheight corona is using seems far to high and the inability to change it is Boooooooo. 
I know we are dependent on the operating system’s font rendering and on Android, it could vary from maker to maker.
Rob
Well, maybe. Â
I’ve been out of the  Corona loops for a little while… I’m going back and updating apps I had last touched in 2012.
Back then, I was using the crawlspace lib’s “newParagraph” function to handle multiline formatting.  It included line height and alignment well better than the current “newText” does.
It seems really “odd” that a 3rd party lib 2 years ago was able to do it better than the current built in system.  Give a try on a multi-line with something like AmericanTypewriter at size 18.  It’s not even close to useful without the ability to change the line height.
Of course,  I do partially blame myself for not looking to see if there was just an updated crawlspace lib before re-writing a whole bunch of code to work with the new newText.  Still can’t help be a bit disappointed that after all this time, writing text with Corona is so painful.
Well ok, I feel a little better that it has NOT been updated. 
But check the newParagraph setup there.  I suppose I could just got back re-wrap a wrapless (no-width) newText call … But seriously, at this age in Corona, it seems we shouldn’t have to do that just to get lineheight control.
I can ask the Engineers to look into this, but they are going to want a bug report. The bug report needs to have any assets needed to run it, and a config.lua and build.settings in a .zip file.
Rob
… Sure –  Or anyone could save the trouble of that just drop this at the top of any ole main.lua they have sitting around real quick for an example – or see the screenshot attached (see bottom of post) – or try just actually using the language for a purpose other than a game.  ;-)
local options = { text = "This is a long line of text that shows how much line height is used. On small screens, space is a premium commodity and this is a waste.", width = display.contentWidth\*.85, font="AmericanTypewriter-Bold", fontSize = 20, align = "center" } local tmpText = display.newText (options) tmpText.x = display.contentWidth/2; tmpText.y = display.contentHeight/2 - 100; local options = { text = "Meanwhile, the line height on this font is not so bad... but given screenspace, there is STILL room that a developer might want to salvage.", width = display.contentWidth\*.85, font=native.systemFont, fontSize = 24, align = "center" } local tmpText = display.newText (options) tmpText.x = display.contentWidth/2; tmpText.y = display.contentHeight/2 + 120; if (1==1) then return true end;
Also, note that when you go to add code to a post here in the forum, Lua is oddly not an options in the menu.  Granted, that’s not needed – but given that this is a Lua oriented forum.
… And then here’s a quick real-world example of where the space is causing problems in our “Character Prompts” app…
This is just one example on one screen of one app.  But you can see that we don’t need that kind of line spacing for any of these fields.  They would be much better off scrunched together a little.  It looks very cluttered because trait and hobby, in particular are spread so much.  Favorite saying also takes up much more room than it needs to via the newText() line height.
Character Prompts is currently in the store using the “old way” and crawlspace…
https://itunes.apple.com/us/app/character-prompts/id493346374
If you want Engineering to look at this, there has to be a trackable entry in the bug database. Engineering does not use Forums as means to allocate and track their work.Â
That said, I don’t see that much of an issue above. Fonts, in particular once you get away from the main font foundries and heavily tested fonts and into free fonts, you will find that there are tons of “metric” problems with them. These metric issues manifest themselves in things like the characters sitting too high in their box, being too short for the space asked for etc.
I don’t know what we can do since we hand the font to the OS and get an image back and there’s not much in between. I don’t know if we can specify a line height or not when we ask the OS to render the text, but that is the most likely scenario. We can’t analyze every font.
Rob
I wouldn’t expect Corona to analyze every font.
I’d just like the ability to set the line height myself if I don’t like the default.
It’s really one of those basic stylization things that most designers have an interest in tweaking.
I also posted a screenshot above from our real world app that it does cause a problem with.  I will have to use a different font or use/update the newParagraph function from the crawlspace lib.  My point still being that line height control is a basic thing that folks shouldn’t have to write wrappers for in 2014.
I am very interested in this feature too. Same as paulscottrobson, we are using Corona as business app too.
Without this feature, the whole reading experience is not superb.
Strongly need this feature.
Thanks.